Plain cmake #63

jontje · 2019-11-13T15:27:34Z

Draft PR that turns the library into a plain cmake package, and it aims to solve issue #3.

The main reason for this is to be able to build and use the library regardless if e.g.:

Ubuntu or Windows
ROS or ROS2

traversaro

Some comments. Probably none of those is blocking the merge, but I think you may find some of them interesting.

CMakeLists.txt

traversaro · 2019-11-13T16:50:01Z

CMakeLists.txt

-                    ${Boost_INCLUDE_DIRS}
-                    ${PROTOBUF_INCLUDE_DIRS}
-                    ${catkin_INCLUDE_DIRS})
+add_library(${PROJECT_NAME} SHARED ${SRC_FILES})


There is any specific reason why you won't leave the user the possibility of selecting the type of the library (SHARED or STATIC) using the standard BUILD_SHARED_LIBS variable? If you want to default to use SHARED, you can simply declare the BUILD_SHARED_LIBS variable as an option whose default value is ON, as suggested in CMake docs itself: https://cmake.org/cmake/help/v3.6/variable/BUILD_SHARED_LIBS.html . This would simplify packaging this lib for vcpkg (https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019).

No reason, it was like that in the generated cmake package template (from the ROS2 command line interface) that I used as a base. I.e. the template found here.

I like your arguments for making it an option instead.

No reason, it was like that in the generated cmake package template (from the ROS2 command line interface) that I used as a base. I.e. the template found here.

I like your arguments for making it an option instead.

Thanks, I know where to open an issue to ask to make it an option then. :D

CMakeLists.txt

traversaro · 2019-11-13T16:52:59Z

CMakeLists.txt

+  PUBLIC ${Boost_INCLUDE_DIRS}
+  PUBLIC ${Protobuf_INCLUDE_DIRS}
+)
+target_link_libraries(${PROJECT_NAME}


If Boost and Protobuf headers are used in the public headers of the libraries, I suggest to mark them as PUBLIC .

Sorry for my lack of knowledge, but could you explain how to mark them as PUBLIC? Doesn't lines 68-69 already do that?

Sorry for my lack of knowledge, but could you explain how to mark them as PUBLIC? Doesn't lines 68-69 already do that?

Lines 68-69 tells the preprocessor of the downstream compilation unit that uses abb_libegm the include directories of Boost and Protobuf need to be appended to the search path of includes (tipically on GCC this is done via the -I compilation option).

Marking as PUBLIC (by doing target_link_libraries(${PROJECT_NAME} PUBLIC ${Boost_LIBRARIES} ${Protobuf_LIBRARIES}) the linked libraries, tells the linker of the downstream library that uses abb_libegm, to also link the Protobuf and Boost libraries when abb_libegm is linked. This is typically done (in *nix) via the -l linker option.
With CMake >= 3.9, you can just declare as PUBLIC in target_link_libraries the linking of the Boost's and Protobuf's imported targets, and that includes both passing the right library to the linker, and the right include dirs to the preprocessor, thanks to the use of so-called "Usage Requirements", see https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements . If you want a more in-depth discussion, the best reference for this that I ever found is the book https://crascit.com/professional-cmake/ , but it is not available free of charge.

traversaro · 2019-11-13T16:55:28Z

CMakeLists.txt

+)
+
+# Create the ${PROJECT_NAME}Config.cmake.
+set(CONF_INCLUDE_DIRS "${CMAKE_INSTALL_PREFIX}/include")


This will point to the wrong include dirs if during configuration the user change the GNUInstallDirs's variable CMAKE_INSTALL_INCLUDEDIR . Furthermore, the include directories are already included in the imported target, so there are more maintainable ways of exporting this info ensuring that the package remains relocatable.

cmake/abb_libegmConfig.cmake.in

traversaro · 2019-11-13T17:03:57Z

cmake/abb_libegmConfig.cmake.in

+#  abb_libegm_LIBRARIES    - libraries to link against
+#  abb_libegm_EXECUTABLE   - the bar executable
+
+set(abb_libegm_INCLUDE_DIRS "@CONF_INCLUDE_DIRS@")


If you are already exporting properly configured CMAke exported targets, there is little use in having an explicit variable ${abb_libegm_INCLUDE_DIRS}, as any use of this variable in downstream package will make them non-relocatable. However, if you want to include it, you can extract it directly from the abb_libegm imported target:

get_target_property(abb_libegm_INCLUDE_DIRS abb_libegm INTERFACE_INCLUDE_DIRECTORIES)

clearly this line should go after the inclusion of the export_abb_libegm.cmake file.

traversaro · 2019-11-13T17:05:13Z

cmake/abb_libegmConfig.cmake.in

+set(abb_libegm_INCLUDE_DIRS "@CONF_INCLUDE_DIRS@")
+
+# Our library dependencies (contains definitions for IMPORTED targets)
+include("${abb_libegm_DIR}/export_abb_libegm.cmake")


The classical trick is to use ${CMAKE_CURRENT_LIST_DIR} to import file that are in the same directory,to avoid assuming that a variable called abb_libegm_DIR is present.

See https://cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html#creating-a-package-configuration-file .

I see, thanks for the pointer!

gavanderhoorn · 2019-11-14T09:12:36Z

A high-level comment: we'll have to decide which versions of OS we'd like to support here: Ubuntu Xenial (still supported till April 2021) comes with CMake 3.5.1 by default.

While CMake can be upgraded -- even using a Kitware supported apt repository -- this doesn't solve the problems of dependencies not necessarily being up-to-speed with modern CMake.

This PR in its current form would already exclude use of Xenial, due to the cmake_minimum_required(VERSION 3.6).

gavanderhoorn · 2019-11-14T12:41:50Z

@jontje: I've just added 1576b74 which adds a build for Dashing.

traversaro · 2019-11-14T13:57:20Z

A high-level comment: we'll have to decide which versions of OS we'd like to support here: Ubuntu Xenial (still supported till April 2021) comes with CMake 3.5.1 by default.
This PR in its current form would already exclude use of Xenial, due to the cmake_minimum_required(VERSION 3.6).

The fact that Xenial was already excluded is the reason why I suggest requiring CMake 3.9 .
If we want instead to keep compatibility with Xenial and CMake 3.5, probably it would be too much effort to be prepare a relocatable package.

While CMake can be upgraded -- even using a Kitware supported apt repository -- this doesn't solve the problems of dependencies not necessarily being up-to-speed with modern CMake.

If this was related to the Protobuf or Boost, what needs to be recent to have imported targets is not the Protobuf or Boost version, but the FindBoost.cmake and FindProtobuf.cmake shipped with CMake, and in their case the CMake imported targets are defined there and not in any Protobuf/Boost file.

jontje · 2019-11-14T15:37:04Z

A high-level comment: we'll have to decide which versions of OS we'd like to support here: Ubuntu Xenial (still supported till April 2021) comes with CMake 3.5.1 by default.

I was not considering that. The reason I put 3.6 is that I thought FindProtobuf set variables as Protobuf_ instead of PROTOBUF_, according to 3.5 and 3.6 respectively.

But I tested with cmake 3.10.2 just now, and then it seems that both Protobuf_ and PROTOBUF_ variables are populated. Is this usually the case between cmake versions? I.e. for backwards-compatibility?

Regardless, then I think it would be good to still support Ubuntu Xenial from the get-go.

traversaro · 2019-11-14T15:40:08Z

Regardless, then I think it would be good to still support Ubuntu Xenial from the get-go.

Ack, then feel free to drop all the comments about non-relocatable packages, as the complexity of doing that with CMake <= 3.9 is probably not worth the gain.

traversaro · 2019-11-14T16:59:55Z

include/abb_libegm/visibility_control.h

+  #define ABB_LIBEGM_PUBLIC_TYPE
+#endif
+
+#endif  // ABB_LIBEGM__VISIBILITY_CONTROL_H_


I guess also this comes from the ros2 template, but unfortunately this template is based on the wrong section of the Wiki page https://gcc.gnu.org/wiki/Visibility . This is based on the section "How to use the new C++ visibility support" that is meant to be a quick overview of the functionality, while the template to be used is the one under "Step-by-step guide" . The difference are not enormous, but unfortunatly this version will probably create problems when compiling as static library in Windows, see ament/ament_cmake#201 (comment) . Again, I do not care too much about building as a static library per se, but supporting that case is useful to easily submit a port of a C++ library to https://github.com/microsoft/vcpkg , that is a great way to manage C++ libraries on Windows.

Yes, it comes from the ROS2 template and I will make an update to address this.

Also, thanks for all the insights! They are much appreciated!

Yes, it comes from the ROS2 template and I will make an update to address this.

I imagined, I will try in the future to report this problems also there!

gavanderhoorn · 2019-11-14T18:03:34Z

Interestingly the ROS 2 build succeeded. The ROS 1 build didn't.

I haven't looked into it yet.

jontje · 2019-11-15T11:32:40Z

Interestingly the ROS 2 build succeeded. The ROS 1 build didn't.

I haven't looked into it yet.

As far as I could see, then it is the cmake version 3.6 requirement that made the ROS 1 build fail, due to ROS Kinetic distribution.

gavanderhoorn · 2019-11-15T11:56:17Z

Interestingly the ROS 2 build succeeded. The ROS 1 build didn't.
I haven't looked into it yet.

As far as I could see, then it is the cmake version 3.6 requirement that made the ROS 1 build fail, due to ROS Kinetic distribution.

yes, looks like it.

jontje · 2019-11-15T17:50:06Z

@traversaro and @gavanderhoorn, I think I have addressed most of your comments (except the ones related to relocation).

Thanks a lot for your valuable remarks!

traversaro · 2019-11-16T13:05:17Z

CMakeLists.txt


 #############################
 ## Google Protocol Buffers ##
 #############################
-find_package(Protobuf REQUIRED)
+if(WIN32)
+  # The protobuf compiler appears to be default installed at ${_CMAKE_INSTALL_DIR}/tools/protobuf,


It may be worth to mention in the comment "appears to be default installed" refers to Chocolatey-based ROS/ROS2 installs.

CMakeLists.txt

traversaro · 2019-11-16T13:19:50Z

cmake/abb_libegmConfig.cmake.in

+include("${CMAKE_CURRENT_LIST_DIR}/abb_libegmTargets.cmake")
+
+# Extras for our library (exports the dependency on pthread)
+include("${CMAKE_CURRENT_LIST_DIR}/abb_libegmExtras.cmake")


I just realized that list(APPEND CMAKE_CXX_FLAGS -pthread) contained in this file will probably break any downstream user of the package on Windows/MSVC that calls find_package(abb_libegm REQUIRED) , as -pthread is not a valid C++ flag in Windows/MSVC (cc @AlbertoRemusIIT) . I guess the CI is not testing this, so we did not realize that.

Probably the CMake idiomatic way of dealing with this is to add find_package(Threads REQUIRED) and a target_link_libraries(${PROJECT_NAME} PUBLIC Threads::Threads), and then add:

include(CMakeFindDependencyMacro) find_dependency(Threads REQUIRED)

here in the abb_libegmConfig.cmake.in before the inclusion of the abb_libegmTargets.cmake file.

jontje · 2019-11-22T13:27:12Z

As soon as abb_libegm is compiled as a static library, everything works fine. So, unless I am missing something, the library was never tested by linking to an executable when compiled as shared in Windows?

I have linked the libary as shared to an executable in Windows and got it to work. But I have tested a bit more and if I use the mutable_<field> accessors, then it works but not with the <field> version. Then I get similar errors as you posted.

E.g.:

abb::egm::wrapper::Output output;
output.mutable_robot()->mutable_joints()->mutable_position()->values_size(); // Works
output.robot().joints().position().values_size(); // Doesn't work

Fortunately, the protobuf generator of C++ files permits to declare a decorator to add to all the symbols to export via the dllexport_decl command line option, that is also exposed as a EXPORT_MACRO in the protobuf_generate_cpp CMake function ( https://cmake.org/cmake/help/v3.9/module/FindProtobuf.html ).

Is this only for CMake 3.9 and newer? If I looked at older documentation that option doesn't seem to exist. Would it be possible to add some if-case for Windows which uses a macro that expands to either __declspec(dllexport) or __declspec(dllimport)? Does it even make sense?

There may be other solutions, such as do a post-processing of the protobuf generated headers to add the include headers via CMake, but I feel they are out of the scope of this PR, and for the time being the easiest solution is to force the library to be compiled as static in Windows.

Yes, that might be the easiest solution for now. So something like this? To make static as default on windows.

if(NOT DEFINED BUILD_SHARED_LIBS)
  if(WIN32)
    option(BUILD_SHARED_LIBS "Build dynamically-linked binaries" OFF)
  else()
    option(BUILD_SHARED_LIBS "Build dynamically-linked binaries" ON)
  endif()
endif()

traversaro · 2019-11-22T13:35:38Z

I have linked the libary as shared to an executable in Windows and got it to work. But I have tested a bit more and if I use the mutable_<field> accessors, then it works but not with the <field> version. Then I get similar errors as you posted.

~~That is interesting, and in that executable you included the .pb.h headers of the generated protobuf messages?~~ (Edit: clearly you included the headers to use the mutable accessors). However, this may suggest to it could make sense to add a small smoke compilation test to the repo only when BUILD_TESTING is defined, to make sure that we don't have regression of this kind (the test can also just be used to verify that the linking works fine, and not do anything when executed).

traversaro · 2019-11-22T13:47:35Z

Yes, that might be the easiest solution for now. So something like this? To make static as default on windows.
if(NOT DEFINED BUILD_SHARED_LIBS)
  if(WIN32)
    option(BUILD_SHARED_LIBS "Build dynamically-linked binaries" OFF)
  else()
    option(BUILD_SHARED_LIBS "Build dynamically-linked binaries" ON)
  endif()
endif()

As BUILD_SHARED_LIBS is broken on Windows, I would probably just avoid to set it as an option, so simply:

 if(NOT DEFINED BUILD_SHARED_LIBS)
   if(WIN32)
       # Add a reference to an issue on the problem with protobuf
     set(BUILD_SHARED_LIBS  OFF)
   else()
     set(BUILD_SHARED_LIBS "Build dynamically-linked binaries" ON)
   endif()
endif()

traversaro · 2019-11-22T13:49:34Z

Fortunately, the protobuf generator of C++ files permits to declare a decorator to add to all the symbols to export via the dllexport_decl command line option, that is also exposed as a EXPORT_MACRO in the protobuf_generate_cpp CMake function ( https://cmake.org/cmake/help/v3.9/module/FindProtobuf.html ).

Is this only for CMake 3.9 and newer? If I looked at older documentation that option doesn't seem to exist. Would it be possible to add some if-case for Windows which uses a macro that expands to either __declspec(dllexport) or __declspec(dllimport)? Does it even make sense?

Yes, I think it make sense to have a check on the CMake version that is greater then 3.9 to add that option. Furthremore, it is also possible to force that the cmake minimum required version is 3.9 on Windows, as typically Windows user do not have any requirement on being compatible with older CMake versions.

traversaro · 2019-11-22T14:31:48Z

Based on the answer in https://stackoverflow.com/questions/17980467/protocol-buffers-generate-non-inline-accessors , I was able to fix the linking problem for shared library in MSVC by adding the following CMake code:

if(MSVC)
  cmake_minimum_required(VERSION 3.9)
else()
  cmake_minimum_required(VERSION 3.5)
endif()

# ... 

if(MSVC)
  protobuf_generate_cpp(EgmProtoSources EgmProtoHeaders EXPORT_MACRO ABB_LIBEGM_PUBLIC ${EgmProtoFiles})
else()
  protobuf_generate_cpp(EgmProtoSources EgmProtoHeaders ${EgmProtoFiles})
endif()

# ...

if(MSVC)
  target_compile_options(${PROJECT_NAME} PUBLIC "/FIabb_libegm/visibility_control.h")
endif()

The /FI is used to force the inclusion of a given header for all the compilation units that link abb_libegm. The solution is a bit brittle, but for sure it is more simple then implementing a custom generator or a protoc wrapper as done in Chromium ( protocolbuffers/protobuf#4198 (comment) ).

gavanderhoorn · 2019-11-22T14:50:51Z

This is not directed at anyone here, but really, how ugly and convoluted can we make a build script?

And then people complain that Catkin / Ament are unnecessary / convoluted / too complex.

I'm actually happy that we have a set of CMake functions/macros that takes care of some of the boilerplate stuff when exporting and importing dependencies.

traversaro · 2019-11-22T16:01:45Z

This is not directed at anyone here, but really, how ugly and convoluted can we make a build script?

And then people complain that Catkin / Ament are unnecessary / convoluted / too complex.

I'm actually happy that we have a set of CMake functions/macros that takes care of some of the boilerplate stuff when exporting and importing dependencies.

Related to that, there are some related issues in upstream CMake on how to simplify the process of exporting CMake packages, that if implemented would reduce drastically the amount of boilerplate code: https://gitlab.kitware.com/cmake/cmake/issues/18634 .

jontje · 2019-11-25T11:31:03Z

However, this may suggest to it could make sense to add a small smoke compilation test to the repo only when BUILD_TESTING is defined, to make sure that we don't have regression of this kind (the test can also just be used to verify that the linking works fine, and not do anything when executed).

That's a good idea, but maybe do it in another PR?

jontje · 2019-11-25T11:42:13Z

This is not directed at anyone here, but really, how ugly and convoluted can we make a build script?

Any suggestion for solving the issue?

Maybe require CMake 3.9 anyway? Is it "bad practice" to hide away code in a cmake module? If not, perhaps that would make the CMakeLists file clearer.

To me it seems a bit tricky to get the library to build properly, without some unfortunate special cases. Regardless, I really appreciate all the time you guys (@gavanderhoorn and @traversaro) have spent on this PR so far.

traversaro · 2019-11-25T11:46:54Z

That's a good idea, but maybe do it in another PR?

Yes totally, also for the Windows+Shared I think it make sense to do that in another PR.

traversaro · 2019-11-27T11:11:19Z

CMakeLists.txt

+#########################
+## Boost C++ Libraries ##
+#########################
+find_package(Boost REQUIRED COMPONENTS regex system thread)


I noticed that the regex component is not used at all, and it was not present in the previous build system.

Suggested change

find_package(Boost REQUIRED COMPONENTS regex system thread)

find_package(Boost REQUIRED COMPONENTS system thread)

I can't build the libary on Windows (at least with ROS and catkin_make_isolated) if I don't specify regex. I don't really know why and I haven't had time to look into it.

I get this linking error:

LINK Pass 1: command "C:\PROGRA~2\MICROS~3\2017\PROFES~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo @CMakeFiles\abb_libegm.dir\objects1.rsp /out:abb_libegm.dll /implib:abb_libegm.lib /pdb:C:\win_ros\ros\win_catkin_ws\build_isolated\abb_libegm\devel\abb_libegm.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /DEF:CMakeFiles\abb_libegm.dir\exports.def C:\opt\rosdeps\x64\lib\boost_system-vc141-mt-x64-1_66.lib C:\opt\rosdeps\x64\lib\boost_thread-vc141-mt-x64-1_66.lib C:\opt\rosdeps\x64\lib\libprotobuf.lib C:\opt\rosdeps\x64\lib\boost_chrono-vc141-mt-x64-1_66.lib C:\opt\rosdeps\x64\lib\boost_system-vc141-mt-x64-1_66.lib C:\opt\rosdeps\x64\lib\boost_date_time-vc141-mt-x64-1_66.lib C:\opt\rosdeps\x64\lib\boost_atomic-vc141-mt-x64-1_66.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\abb_libegm.dir/intermediate.manifest CMakeFiles\abb_libegm.dir/manifest.res" failed (exit code 1104) with the following output: LINK : fatal error LNK1104: cannot open file 'boost_regex-vc141-mt-x64-1_66.lib'

Sorry, I had no idea, probably there is some non-declared internal boost dependency, in that case indeed leaving regex is indeed a nice workaround.

jontje · 2019-12-18T14:32:35Z

I have created a new branch that I think would clean-up the CMake files, as well as added @traversaro's example for fixing the linking issue on Windows. I didn't add it to this PR yet, since I has been waiting for some comments from @gavanderhoorn, but I think this will have to wait until next year.

gavanderhoorn · 2020-01-15T15:07:47Z

Getting back to this I think we can merge this as-is.

One comment: this will break peoples workspaces when they are currently using abb_libegm and building it with catkin_make (as plain catkin doesn't support plain cmake packages).

We should add a section to the readme explaining this is a pure CMake package and that ROS users should use catkin_tools to build it (or colcon).

gavanderhoorn

We can merge this.

Let's fix other issues in follow-up PRs.

gavanderhoorn · 2020-01-15T15:27:36Z

I'll leave the merge to you @jontje.

Could you also update the readme?

We should also post about this breaking change on ROS Discourse. I can do that if you'd like. Let me know.

gavanderhoorn · 2020-01-15T15:41:26Z

CMakeLists.txt

-list (REMOVE_ITEM PROTOBUF_LIBRARIES "-lpthread")
+if(WIN32)
+  # For a Chocolatey-based ROS/ROS2 installation, then it appears that the protobuf compiler is
+  # by default installed at ${_CMAKE_INSTALL_DIR}/tools/protobuf, and find_package() doesn't


Just noticed this: _CMAKE_INSTALL_DIR.

Is that actually a variable?

Yes, even if a non-documented/unsupported one (see https://gitlab.kitware.com/cmake/cmake/blob/v3.16.2/Modules/Platform/WindowsPaths.cmake#L49). It works fine only because in Chocolatey-based ROS/ROS2 installations CMake and protobuf are installed in the same install prefix.

even if a non-documented/unsupported one

hm ...

even if a non-documented/unsupported one

hm ...

Not a big fan of it either, especially as it does not work with a vcpkg-installed protobuf. : )

gavanderhoorn · 2020-01-15T15:46:16Z

CMakeLists.txt

-        FILES_MATCHING PATTERN "*.h")
+install(
+  FILES
+    ${EgmProtoFiles}


Should these go to CMAKE_INSTALL_DATAROOTDIR instead?

I am not sure if there is any policy/best practice for this, but for example the ignition-msgs package installs them in the same include directories of C++ include headers, see https://packages.debian.org/sid/amd64/libignition-msgs-dev/filelist . Perhaps @j-rivero knows about some policy regarding this.

jontje · 2020-01-22T12:07:42Z

Thanks for the reviews @traversaro and @gavanderhoorn! 👍

I'll leave the merge to you @jontje.

Could you also update the readme?

We should also post about this breaking change on ROS Discourse. I can do that if you'd like. Let me know.

I will update the readme, and you are more than welcome to post on ROS Discourse this time @gavanderhoorn 😄

gavanderhoorn · 2020-01-22T12:25:16Z

Done: Conversion to plain CMake of abb_libegm (and abb_librws).

gavanderhoorn · 2020-01-22T12:25:32Z

You will update the readme?

jontje · 2020-01-22T14:21:57Z

You will update the readme?

Yes, I will do that.

jontje added 6 commits November 8, 2019 11:01

Updated package.xml

3394f0a

Added visibility control header

0a3368a

Added cmake config input files

4ad7d8b

Updated CMakeList.txt file for Ubuntu

d70c144

Updated CMakeList.txt file for Windows

b65bc9d

Included visibility control

4ff987f

jontje mentioned this pull request Nov 13, 2019

Convert to pure CMake package #3

Closed

traversaro reviewed Nov 13, 2019

View reviewed changes

cmake/abb_libegmConfig.cmake.in Outdated Show resolved Hide resolved

traversaro reviewed Nov 13, 2019

View reviewed changes

gavanderhoorn mentioned this pull request Nov 14, 2019

Plain cmake ros-industrial/abb_librws#69

Merged

travis: add Dashing build

1576b74

travis: use master branch for ROS2 support

e79f08b

traversaro reviewed Nov 14, 2019

View reviewed changes

gavanderhoorn and others added 3 commits November 15, 2019 13:15

travis: NOT_TEST_INSTALL is not needed any more.

53e9e28

Improved and cleaned-up CMakeLists.txt

de25ff0

Updated visibility control

43a88c7

traversaro reviewed Nov 16, 2019

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

traversaro reviewed Nov 16, 2019

View reviewed changes

Use GenerateExportHeader instead of custom implementation

3ad2428

jontje mentioned this pull request Nov 26, 2019

Investigate version detection of EGM protocol #46

Closed

traversaro reviewed Nov 27, 2019

View reviewed changes

gavanderhoorn mentioned this pull request Dec 6, 2019

Protobuf headers not found when compiling with CMI #65

Closed

gavanderhoorn approved these changes Jan 15, 2020

View reviewed changes

traversaro approved these changes Jan 15, 2020

View reviewed changes

gavanderhoorn reviewed Jan 15, 2020

View reviewed changes

jontje merged commit fc647bd into ros-industrial:master Jan 22, 2020

jontje deleted the plain_cmake branch January 23, 2020 07:10

traversaro mentioned this pull request Feb 3, 2020

Upstream changes from iit-danieli-joint-lab/abb_libegm fork #70

Open

jontje mentioned this pull request Nov 18, 2020

Added export macro to generated protobuf C++ files, and force include generated export header #113

Merged

gavanderhoorn mentioned this pull request Jan 4, 2021

Does the author permit re-licensing the cmake code for extracting package name and version from package.xml? ros-industrial/abb_robot_driver#8

Closed

	find_package(Boost REQUIRED COMPONENTS regex system thread)
	find_package(Boost REQUIRED COMPONENTS system thread)

Plain cmake #63

Plain cmake #63

Conversation

jontje commented Nov 13, 2019

traversaro left a comment

Choose a reason for hiding this comment

traversaro Nov 13, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

traversaro Nov 14, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

traversaro Nov 13, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gavanderhoorn commented Nov 14, 2019

gavanderhoorn commented Nov 14, 2019

traversaro commented Nov 14, 2019

jontje commented Nov 14, 2019

traversaro commented Nov 14, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gavanderhoorn commented Nov 14, 2019

jontje commented Nov 15, 2019

gavanderhoorn commented Nov 15, 2019

jontje commented Nov 15, 2019

Choose a reason for hiding this comment

traversaro Nov 16, 2019 • edited

Choose a reason for hiding this comment

jontje commented Nov 22, 2019

traversaro commented Nov 22, 2019 • edited

traversaro commented Nov 22, 2019

traversaro commented Nov 22, 2019

traversaro commented Nov 22, 2019 • edited

gavanderhoorn commented Nov 22, 2019

traversaro commented Nov 22, 2019

jontje commented Nov 25, 2019

jontje commented Nov 25, 2019

traversaro commented Nov 25, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jontje commented Dec 18, 2019

gavanderhoorn commented Jan 15, 2020

gavanderhoorn left a comment

Choose a reason for hiding this comment

gavanderhoorn commented Jan 15, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

traversaro Jan 15, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jontje commented Jan 22, 2020

gavanderhoorn commented Jan 22, 2020

gavanderhoorn commented Jan 22, 2020

jontje commented Jan 22, 2020

traversaro Nov 13, 2019 •

edited

traversaro Nov 14, 2019 •

edited

traversaro Nov 13, 2019 •

edited

traversaro Nov 16, 2019 •

edited

traversaro commented Nov 22, 2019 •

edited

traversaro commented Nov 22, 2019 •

edited

traversaro Jan 15, 2020 •

edited