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

Downstream packaging patchset #231

Open
wants to merge 16 commits into
base: main
Choose a base branch
from
Open

Downstream packaging patchset #231

wants to merge 16 commits into from

Conversation

leamas
Copy link

@leamas leamas commented Sep 24, 2020

EDIT: Rewritten docs after a rebase update.

An admittedly large patch set from the downstream Debian packaging:

  • Fix the missing so-version i. e., a defined ABI level (Packaging problems: soversion, deps #194)
  • Add some standard cmake configuration, PROJECT, PUBLIC_HEADER etc.
  • Add an official configuration switch ENABLE_TEST_PROGRAM to build the test program
  • Probe for doxygen, use it to build the docs if available.
  • Make the CATKIN_ENABLE_TESTING an official option, makes it visible in cmake help etc.
  • Don't include the ubiquitous v8stdint.h in package unless its' actually used.
  • Add an option to build using the alternative package name cxx-serial to avoid name conflicts when using the generic serial, by default off.
  • Fix the timing tests, now works on both MacOS and Linux.
  • ci updates:
    • Add a travis build on Ubuntu Focal (as of today, all travis builds are broken). The existing, broken builds are left as-is after refactoring .travis.yml (Travis ci tests fails for linux and macOS #230). Update the xenial config to build a catkin package
    • Add a appveyor.yml configuration building the win32 library
    • Add a circleci configuration building Macos.

Closes: #194
Closes: #232
Closes: #230

These changes (besides the ci updates) will go into an upcoming Debian version. The current 1.2.1-3 contains a limited set.

Travis build logs Focal, Xenial
CircleCI build logs: MacOS, Focal

The patches are reasonably separate, cherry-picking should be possible.

Cmake made major changes in the 2.x -> 3.0 switch, keeping the 2.x
compatiblity just isn't worth it. Since serial anyway doesn't build on
versions before xenial, use xenial's cmake at 3.5 as baseline.

Gbp-Pq: Name 0001-cmake-Use-cmake-3.5-add-project-setup.patch
Adding a so-version means defining an ABI level. This level is decoupled
from the ordinary version, even a major version change doesn't
necessarily mean that the so-version should change (and thus have all
dependencies to be rebuilt).

Adding the public header to clarify the setup.

Gbp-Pq: Name 0002-cmake-Add-defined-so-version-and-public-header-to-li.patch
Gbp-Pq: Name 0004-cmake-Make-test-program-depend-on-ENABLE_TEST_PROGRA.patch
Gbp-Pq: Name 0005-cmake-Use-doxygen-for-docs-if-found.patch
Gbp-Pq: Name 0006-cmake-Make-CATKIN_ENABLE_TESTING-an-offial-option.patch
Make sure that in cases v8stdint.h is not used it's not even included in
the package.  Installation of this file is problematic when packaged
since the file is used also in other packages and leads to installation
conflicts.

Gbp-Pq: Name 0007-cmake-include-Make-use-of-v8stdint.h-conditional.patch
The name serial is problematic when packaging since it's basically too
generic and easily generates name clashes. Add an option which builds
the package as cxx-serial instead, by default off to not break existing
usage.

Gbp-Pq: Name 0008-cmake-Add-option-for-alternative-name-cxx-serial.patch
Compute actually elapsed time instead of assuming that usleep() sleeps
for exactly the right time, which isn't guaranteed.
Although this patch better matches the state before the re-factoring, it
doesn't mean that much since the build breaks already in the install
stage.

While on it, fix some yamllint nitpicks.
The existing targets for precise and osx breaks, both on dependencies.
Seems to be about the 'rosdep install'  command in the Makefile(?),
which is beyond my current scope.

Add a new target for Ubuntu focal which works after refactoring the
.travis.yml file.

Gbp-Pq: Name 0011-ci-.travis.yml-Refactor-add-working-focal-build.patch

travis
@leamas
Copy link
Author

leamas commented Sep 29, 2020

Rebased & enhanced. See initial comment (edited)

@wjwwood
Copy link
Owner

wjwwood commented Jun 10, 2021

Not sure I can take this in the current form, but I'll try to incorporate each of these things in the next version where I will be redoing CI (with GitHub Actions) and removing the catkin support in favor of pure CMake.

)
else()
# Otherwise normal call
option(USE_CXX_SERIAL "build package name cxx-serial" OFF)
Copy link

Choose a reason for hiding this comment

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

I would prefix all options using SERIAL_ so it can be properly regrouped in cmake GUI. What do you think?

Copy link
Author

Choose a reason for hiding this comment

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

Late to the party... but really no opinion about it, I never use the GUI...

# Otherwise normal call
option(USE_CXX_SERIAL "build package name cxx-serial" OFF)
if (USE_CXX_SERIAL)
set(PKG_NAME cxx-serial)
Copy link

Choose a reason for hiding this comment

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

Why not renaming this library as wjwserial? This remove useless clashes and make the cmakelist simpler

Copy link
Author

Choose a reason for hiding this comment

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

Because renaming the library basically means to fork it, and this is not what I intend to do.

add_subdirectory(tests)
endif()

if (DISABLE_CATKIN)
Copy link

Choose a reason for hiding this comment

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

Not sure why this has been if'ed on CATKINS

Copy link
Author

Choose a reason for hiding this comment

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

So it can be built without the catkins dependency.

Comment on lines +47 to +51
#ifdef HAVE_STDINT_H
#include <stdint.h>
#else
#include <serial/v8stdint.h>
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

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

To use the downstream libcxx-serial-dev I had to define HAVE_STDINT_H because the debian installs <serial/v8stdint.h> to /usr/include/v8stdint.h

https://packages.ubuntu.com/focal/amd64/libcxx-serial-dev/filelist

https://packages.ubuntu.com/jammy/amd64/libcxx-serial-dev/filelist

PickNikRobotics/ros2_robotiq_gripper#22 (comment)

Copy link
Author

Choose a reason for hiding this comment

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

Yes. A proper packaging would make sure that this compilation constant was set as defined by cmake. That is, this is actually a packaging bug.

Copy link
Author

Choose a reason for hiding this comment

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

Yes, this is a bug. This -D should be set automatically when building the package, as defined by cmake.

The simple solution would be to use target_add_definitions to add a compile flag to the target. The more elaborated approach would be to create a config.h file which would be included by all source files; this makes sense if there are more configuration which needs to be used in the sources.

Copy link
Owner

Choose a reason for hiding this comment

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

Also, when this was written like 15 years ago this was needed, but now I think we could do without the v8stdint.h hack entirely.

Copy link
Owner

Choose a reason for hiding this comment

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

Since this is C++, we can use <cstdint> and require C++11.

Copy link
Author

Choose a reason for hiding this comment

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

Yup, that' a better approach, agreed

Comment on lines +3 to +4
<name>@PROJECT_NAME@</name>
<version>@PROJECT_VERSION@</version>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does rosdep support package.xml -> package.xml.in when using rosdep to install all dependencies?

Copy link

Choose a reason for hiding this comment

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

Not that I've been able to. If the project name is constant, then the maintainer just needs to keep this in sync with the CMakeLists, which is what most of the other packages do anyways.

Copy link
Author

Choose a reason for hiding this comment

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

As I understand this at a glance, rosdep is not aware of package.xml.in , it only uses package.xml which is updated at each cmake invocation

If the project name is constant, then the maintainer just needs to keep this in sync with the CMakeLists, which is what most of the other packages do anyways.

Indeed. However, the version is not constant.

Copy link
Owner

Choose a reason for hiding this comment

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

You can't do this, sorry. The package.xml needs to exist before building.

Copy link
Author

Choose a reason for hiding this comment

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

It complicates the upstream maintenance, having especially the version in both CMakeLists and package.xml is not optimal.

It could be done the other way around: CMakeLists reads the version from package.xml. That would also be a consistent setup.

However, from a packaging perspective it doesn't really matter, so let's drop this for now

Choose a reason for hiding this comment

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

It could be done the other way around: CMakeLists reads the version from package.xml. That would also be a consistent setup.

Dart does exactly this: https://github.com/dartsim/dart/blob/main/CMakeLists.txt#L29 .

Copy link
Author

Choose a reason for hiding this comment

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

Yes. Even better would be to scan package.xml before the cmake project() invocation. If done this way the version could be set in project(...); cmake has some nice provisions to set up standard variables from this.

Comment on lines -23 to -24
#include <boost/bind.hpp>

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this can be removed from the package.xml too

Copy link
Author

Choose a reason for hiding this comment

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

hm...

$ git grep bind.hpp
tests/proof_of_concepts/tokenizer.cc:#include <boost/bind.hpp>

Copy link
Author

Choose a reason for hiding this comment

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

however, 2070f8a gets rid of this dep

Copy link
Collaborator

Choose a reason for hiding this comment

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

The tests/proof_of_concepts directory seems to be dead code that's not being built

moriarty pushed a commit to moriarty/serial that referenced this pull request Jun 15, 2023
Cmake made major changes in the 2.x -> 3.0 switch, keeping the 2.x
compatiblity just isn't worth it. Since serial anyway doesn't build on
versions before xenial, use xenial's cmake at 3.5 as baseline.

Cherry-pick from PR wjwwood#231

 Conflicts:
	CMakeLists.txt
 Author:    Alec Leamas <[email protected]>
 Date:      Tue Sep 22 13:08:46 2020 +0200

Gbp-Pq: Name 0001-cmake-Use-cmake-3.5-add-project-setup.patch
Signed-off-by: Alex Moriarty <[email protected]>
moriarty pushed a commit to moriarty/serial that referenced this pull request Jun 15, 2023
Adding a so-version means defining an ABI level. This level is decoupled
from the ordinary version, even a major version change doesn't
necessarily mean that the so-version should change (and thus have all
dependencies to be rebuilt).

Adding the public header to clarify the setup.

Note: cherry-pick from PR wjwwood#231

 Conflicts:
	CMakeLists.txt
 Author:    Alec Leamas <[email protected]>
 Date:      Tue Sep 22 13:28:04 2020 +0200

Gbp-Pq: Name 0002-cmake-Add-defined-so-version-and-public-header-to-li.patch
Signed-off-by: Alex Moriarty <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants