-
Notifications
You must be signed in to change notification settings - Fork 1k
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
base: main
Are you sure you want to change the base?
Conversation
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
Rebased & enhanced. See initial comment (edited) |
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
#ifdef HAVE_STDINT_H | ||
#include <stdint.h> | ||
#else | ||
#include <serial/v8stdint.h> | ||
#endif |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
<name>@PROJECT_NAME@</name> | ||
<version>@PROJECT_VERSION@</version> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 .
There was a problem hiding this comment.
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.
#include <boost/bind.hpp> | ||
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
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 <leamas.alec@gmail.com> 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 <alex.moriarty@picknik.ai>
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 <leamas.alec@gmail.com> 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 <alex.moriarty@picknik.ai>
EDIT: Rewritten docs after a rebase update.
An admittedly large patch set from the downstream Debian packaging:
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.