Project

General

Profile

Actions

Pull request #309

open

new HPP release

Added by Guilhem Saurel 20 days ago. Updated about 23 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Repository URL:
https://github.com/nim65s/robotpkg
Repository branch:
master

Description

Hello !

This update is a bit bigger than the previous ones.
It features:

- hpp-fcl 1.7.2
- eigenpy 2.6.3
- pinocchio 2.6.0
- gepetto-viewer 4.12.0
- gepetto-viewer-corba 5.6.0
- ndcurves 1.1.0
- HPP 4.11.0, including many HPP components that were imported from wip/

While here, I made some cleaning in depend.mk (both for style, to update SYSTEM_SEARCH, and to fix the issue I had in #308 )

Best,
Guilhem.

Actions #1

Updated by Anthony Mallet 20 days ago

I didn't see any blatant issue by just looking at the diff, so I
push it and we'll see. Do you plan to also clean-up wip/ ?

There will be an issue with py27-hpp-affordance-corba, which is the
same as the current issue with hpp-manipulation-corba: they both
depend on hpp-templace-corba, and thus indirectly on omniORB, that
needs python.

hpp-template-corba and omniorb are not prefixed with PKGTAG.python
which creates the problem. I'm not sure if all those should be
prefixed with PKGTAG.python...

Actions #2

Updated by Guilhem Saurel 17 days ago

Hello,

I cleaned wip/, but forgot a package, so the build failed. I just push a fix.

I also catch a C++ standard issue in hpp-util, and pushed a trivial fix, which seems to work.

hpp-pinocchio still didn't on 16.04, because GCC segfaults on a std::remove_if… I'll workaround that.

For the issue with hpp-template-corba, do we already have an error somewhere ?

Actions #3

Updated by Anthony Mallet 17 days ago

On Monday 26 Apr 2021, at 12:14, Guilhem Saurel wrote:

I also catch a C++ standard issue in hpp-util, and pushed a trivial
fix, which seems to work.

Yes, fine.

hpp-pinocchio still didn't on 16.04, because GCC segfaults on a
std::remove_if… I'll workaround that.

I was also looking at that, considering just requiring gcc > 5.5, but
if you have a solution that's also nice.

While there, could you also require hpp-pinocchio > 4.11 by default,
because of the updated PLIST? (package.xml added, which is not found
for earlier versions). An alternative is to not put package.xml in the
SYSTEM_SEARCH, so that older version works too.

For the issue with hpp-template-corba, do we already have an error
somewhere ?

I focused on hpp-pinocchio so far, so I haven't checked yet. Let's see
once the build is a bit cleaner.

Actions #4

Updated by Guilhem Saurel 17 days ago

That's right, it would be nice to just avoid GCC 5.4 here.

On 16.04, the default clang seems to work well. Is there any way to switch to clang if GCC < 5.5 ?

I should definitely have updated all DEPEND_ABI for HPP 4.11. This is generally true for all main HPP upgrades, where the ABI is usually broken in many places.
Since it will be easier to track exceptions, I suggest this:
https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba
(a quick rebuild on 18.04 seems to work)

Actions #5

Updated by Guilhem Saurel 17 days ago

hpp-corbaserver might also have some issue with old GCC: https://github.com/humanoid-path-planner/hpp-corbaserver/issues/137

Actions #6

Updated by Anthony Mallet 17 days ago

On Monday 26 Apr 2021, at 14:14, Guilhem Saurel wrote:

On 16.04, the default clang seems to work well. Is there any way to
switch to clang if GCC < 5.5 ?

The switch between gcc and clang is not currently thought in this way:
this is a user option that is kind of global. I'm not sure it is
always safe to mix clang and gcc object, especially for C++ ... so
the intended consistency seems cleaner.

In addition, the list of dependencies cannot be changed once they
start to be checked, so switching from gcc to clang is not possible
once we know the version of gcc. (Of course it could probably still be
hacked in some way).

Since the problem seems to come from the auto parameter in the lambda,
is it really an issue to use the actual typename instead of auto?
I tried with ::pinocchio::CollisionPair and it built fine (but I've no
idea if this is the right type and why 'auto' was used instead).

I suggest this:
https://github.com/nim65s/robotpkg/commit/47196d0a67d760826ddfd68eff4ec245d7eb65ba
(a quick rebuild on 18.04 seems to work)

I would rather call it "HPP_MIN_VERSION" instead of "MAIN_VERSION" but
otherwise yes, it's a good idea.

Actions #7

Updated by Guilhem Saurel 15 days ago

Hello,

I changed this name: https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c

After a quick survey, it seems OK to forget the HPP binaries for 16.04, so we can go for this:
https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576

Actions #8

Updated by Anthony Mallet 14 days ago

On Wednesday 28 Apr 2021, at 18:51, Guilhem Saurel wrote:

I changed this name:
https://github.com/nim65s/robotpkg/commit/fdca1b91ba90276f5e003d3c3fd288cfd266775c

OK. However, HPP_MIN_VERSION and HPP_VERSION are not the same in
general. Since including a "depend"-like file in a "Makefile" is also
a bad idea (generally speaking), I removed the inclusion and define
hpp version in a standalone way.

After a quick survey, it seems OK to forget the HPP binaries
for 16.04, so we can go for this:
https://github.com/nim65s/robotpkg/commit/9531bb3ca8cc1fe14471e9da3bbd4c0577ef9576

OK. I moved the constraint after inclusion of c++.mk to still get any
default value set there.

Actions #9

Updated by Guilhem Saurel 7 days ago

Hello,

You were right on the issues with PKGTAG.python.
And this PR created a few more: hpp-pinocchio now depends on py-hpp-baxter, so installing hpp-pinocchio installs py27-hpp-baxter version by default.

After that, if one tries to install py36-hpp-baxter, we get an error. I thought that apt would now that those 2 packages are incompatible and remove the py27 before installing py36, but it is not.

First of all, it seems that the PYTHON_SELF_CONFLICT is inverted in meta-pkgs/hpp/Makefile.common.
But then, even in some packages where PYTHON_SELF_CONFLICT looks good, like py-eigenpy, installing robotpkg-py27-eigenpy then robotpkg-py36-eigenpy fails, instead of removing robotpkg-py27-eigenpy to resolve the conflict.

# apt depends robotpkg-py36-eigenpy
robotpkg-py36-eigenpy
  Depends: libboost-python1.65-dev (>= 1.34.1)
  Depends: libeigen3-dev (>= 3.0.0)
  Depends: libstdc++6
  Depends: python3-numpy (>= 1:1)
  Depends: python3.6-minimal (>= 3.6)
  Depends: python3.6-minimal (<< 3.7)
  Depends: libpython3.6-dev (>= 3.6)
  Depends: libpython3.6-dev (<< 3.7)
  Conflicts: robotpkg-py36-eigenpy
  Replaces: robotpkg-py36-eigenpy

I would expect robotpkg-py27-eigenpy here.

On the other hand, this conflict mechanism works well between eg. robotpkg-hpp-fcl & robotpkg-hpp-fcl+doc.

Do you have an idea why this PYTHON_SELF_CONFLICT is not working as intended ? Or maybe did I understand this wrong ?

Actions #10

Updated by Anthony Mallet 2 days ago

I fixed something badly wrong with 50fa64a

I'm not sure this will solve everything, as the initial issue will
remain: pulling a wrong python dependency that is not supposed to be
there (sysdep and not robotpkg package).

Actions #11

Updated by Guilhem Saurel 1 day ago

This is clearly better now, thanks a lot !

There is still a C++98 issue in pinocchio on 16.04, but I'll take care of this in another place.

We also have an issue with between gepetto-viewer-corba and omniORB on debian 9. I can't reproduce it in my development setup: everything works as expected, with omniORB from robotpkg and from debian. But this is not a priority, as I am not aware of anybody needing this binary package on that platform.

Actions #12

Updated by Guilhem Saurel about 24 hours ago

Ok, I spoke too fast. This PYTHON_SELF_CONFLICT behave as intended for eigenpy, but not for HPP packages… I think I found the culprit:
https://github.com/nim65s/robotpkg/commit/97f341111edccf6be835db116d9520901afc8180

While here, I also found a detail: https://github.com/nim65s/robotpkg/commit/4443cd679a4f51112b6ef26afcadd40ce1387e5e

Actions #13

Updated by Anthony Mallet about 23 hours ago

OK, thanks!

Actions

Also available in: Atom PDF