Pull request #408
closedhpp v5
Description
Hello !
We have a new HPP major version.
This add a new dependency, proxsuite, which was in wip, so I moved it and its dependencies.
I'm not sure if this move was done properly, and I didn't remove those packages from wip yet. Also I'm not sure about the categories of those packages.
Some of those packages use the meson build system, but I'm not sure how to use it from robotpkg, so I bypassed it by simply installing all *.h files for 2 header-only libraries. But maybe there is a better way.
Best,
Guilhem
Updated by Anthony Mallet about 1 month ago
I'm not sure if this move was done properly, and I didn't remove
those packages from wip yet. Also I'm not sure about the categories
of those packages.
There were a few trainling wip/ references, and the order of import
was not logical, but no big deal (I still re-ordered the commits in
the order of dependencies and fix a few issues).
Regarding matio, it seems available everywhere (Fedora>=38 only for
Fedora). Do we really need it in robotpkg?
Some of those packages use the meson build system, but I'm not sure
how to use it from robotpkg, so I bypassed it by simply installing
all *.h files for 2 header-only libraries. But maybe there is a
better way.
The better way would be to add the support for it in mk/configure
etc. as for e.g. cmake or py-setuptools, but given the packages in
question, it's probably best to do what you did for now :)
Updated by Guilhem Saurel about 1 month ago
Ok, thanks !
I didn't check about matio system packages, and I'm totally fine to use those instead of packaging it ourself :)
NB: while here, I can see that we have a few other references to wip:
$ rg wip optimization/proxsuite/depend.mk 24:DEPEND_DIR.proxsuite?= ../../wip/proxsuite optimization/py-proxsuite/depend.mk 22:DEPEND_DIR.py-proxsuite?= ../../wip/py-proxsuite optimization/py-casadi/Makefile 18:CATEGORIES= wip supervision/tcl-genomix/depend.mk 22:DEPEND_DIR.tcl-genomix?= ../../wip/tcl-genomix mk/sysdep/gts.mk 25:SYSTEM_PKG.NetBSD.gts=wip/gts mk/sysdep/ftgl.mk 24:SYSTEM_PKG.NetBSD.ftgl= wip/ftgl net/py-poco/Makefile 1:# robotpkg Makefile for: wip/py-poco mk/sysdep/py-pydot.mk 25:SYSTEM_PKG.NetBSD.py-pydot= wip/${PKGTAG.python-}pydot net/py-poco/depend.mk 1:# robotpkg depend.mk for: wip/py-poco motion/sot-romeo/depend.mk 19:DEPEND_DIR.sot-romeo?= ../../wip/sot-romeo
Updated by Anthony Mallet about 1 month ago
On Tuesday 2 Apr 2024, at 18:07, Guilhem Saurel wrote:
I didn't check about matio system packages, and I'm totally fine to
use those instead of packaging it ourself :)
It seems that the 'matdump' tool is missing, at least on ubuntu-20.04
Is it an issue? I think only the lib is used in hpp, right?
So I will keep your upgrade commit for matio in wip/ instead (just in
case), default to system package in wip, and create a sysdep in
robotpkg.
NB: while here, I can see that we have a few other references to
wip:
Yup, I spotted those in proxsuite, but not the others... Thanks!
Updated by Guilhem Saurel about 1 month ago
Yes, we don't need the "matdump" tool
Updated by Anthony Mallet about 1 month ago
There is also an issue with e.g. hpp-core-5.0 not building with
hpp-pinocchio-4.15.1
Should I bump HPP_MIN_VERSION to 5 in meta-pkgs/hpp/depend.common?
Updated by Guilhem Saurel 30 days ago
Yes, plese.
But how did you get into this error ? I would expect both package to keep sync through HPP_VERSION
Updated by Anthony Mallet 30 days ago
On Wednesday 3 Apr 2024, at 15:53, Guilhem Saurel wrote:
Yes, plese. But how did you get into this error ? I would expect
both package to keep sync through HPP_VERSION
With previous hpp-4.x installed, make update in e.g. hpp-core.
hpp-core-5.0 was happy with hpp-pinocchio-4.15.1 installed, since
DEPEND_ABI.hpp-picocchio = hpp-picocchio>=4.11
For the same reason, I also had to bump DEPEND_ABI.example-robot-data
to >=4.1, since previous 3.6 did not define
EXAMPLE_ROBOT_DATA_MODEL_DIR and that was breaking hpp-pinocchio-5.0
Updated by Anthony Mallet 30 days ago
Ideally, the minimum required version of dependencies should be
checked in the packages' CMake too, as this is where this information
is known.
Then it's easy to propagate it in robotpkg :) (and it will report a
clear error if something is wrong).
Updated by Guilhem Saurel 29 days ago
Thanks for fixing the PLIST !
I don't know how this got under my radar.
We'll probably want to remove py-hpp-rbprm & py-hpp-rbprm-corba, which are long broken and no longer maintained.
I've pushed a few "DEPEND_ABI.python= python>=3" on my fork, to clean http://robotpkg.openrobots.org/rbulk/robotpkg/broken.html a bit.
Updated by Anthony Mallet 29 days ago
On Thursday 4 Apr 2024, at 09:37, Guilhem Saurel wrote:
We'll probably want to remove py-hpp-rbprm & py-hpp-rbprm-corba,
which are long broken and no longer maintained.
OK, I'll drop it along with your recent fixes then.
I also have hard times understanding the CMakeFile from py-proxsuite,
it goes into a forest of included .cmake :)
I'm trying to get why it installs a "proxsuiteTargets-release.cmake"
while proxsuite does not. Also it tends to overwrite the headers from
proxsuite under some obscure circumstances (maybe mtime changed),
which is a potential issue.
If I restrict the build/install to 'binding/python' subdir then it's
fine. But of course it's then missing the '.dsv' files... Not sure if
they're useful though, as it's only about PYTHONPATH which is not
special.
Updated by Guilhem Saurel 29 days ago
those .dsv files are only here for ROS2 packaging. I don't think this is super important in robotpkg, where the user is expected to update their env for /opt/openrobots anyways.
Updated by Anthony Mallet 29 days ago
On Thursday 4 Apr 2024, at 11:14, Guilhem Saurel wrote:
those .dsv files are only here for ROS2 packaging. I don't think
this is super important in robotpkg, where the user is expected to
update their env for /opt/openrobots anyways.
OK, so in order do save a few neurons I'll go for just building/installing
in bindings/python and we'll see if someone complains :)
Updated by Guilhem Saurel 25 days ago
Bulk builds are now looking quite good, thanks !
But there are some weird errors with 20.04 .deb files: `apt install robotpkg-proxsuite`:
The following packages have unmet dependencies: robotpkg-proxsuite : Depends: robotpkg-simde (= 0.7.2) but 0.8.0 is to be installed Depends: robotpkg-matio (= 1.5.23r1) but 1.5.26 is to be installed or robotpkg-matio (= 1.5.23) but 1.5.26 is to be installed
On 22.04:
$ apt depends robotpkg-proxsuite robotpkg-proxsuite Depends: robotpkg-visit-struct (= 1.0) Depends: robotpkg-simde (= 0.8.0) Depends: libstdc++6 Depends: libmatio-dev (>= 1.5.17) Conflicts: robotpkg-proxsuite Replaces: robotpkg-proxsuite
Updated by Anthony Mallet 25 days ago
My fault, I forgot to install libmatio-dev sysdep on the ubuntu-2004 bulk
machine.
As a result, only robotpkg-proxsuite-0.2.13r1 from wip/ is available
and it depends on robotpkg-simde-0.7.2 (also from wip/). But since
there is robotpkg-simde-0.8 from robotpkg, apt refuses to install
robotpkg-simde-0.7.2.
I restarted a build, robotpkg-proxsuite-0.6.4 with updated
dependencies should appear shortly for ubuntu-2004.
Updated by Guilhem Saurel 24 days ago
- Status changed from New to Closed
Everything looks good to me now, thanks !