robotpkg

On Wednesday 6 Nov 2019, at 21:11, Guilhem Saurel wrote:

Here are 2 new options for jrl-cmakemodules to update CONFLICTS:
- PYTHON_CONFLICTS for packages which does not support multiple
parallel python version

In pkgsrc this is called "PYTHON_SELF_CONFLICT". I would rather keep
the same name and put this in python.mk, as it is unrelated to
jrl-cmakemodules.

- NEW_PYTHON_PREFIX for package which have been renamed with the
addition of a PKGTAG.python

Can't it be done by default (when USE_PYTHON is yes) ?
I'm not fan of such a temporary variable.

- allow to build interfaces/ros-humanoid-msgs on ros > kinetic

This package is not present in ros > kinetic. So you will have issues
anyway with ros as a system package (and that's just a mistake that
this package is compiled for ros-melodic in robotpkg).

(otherwise, I get an error on building wip/prf-ros-controllers,
stating that no ros version is available at all)

Is the dependency on ros-humanoid-msgs really needed?
I would rather remove this package from robotpkg, as it is obsolete
(and maybe just convert it to a sysdep to support ros <= kinetic).

Here are 2 new options for jrl-cmakemodules to update CONFLICTS:
- PYTHON_CONFLICTS for packages which does not support multiple
parallel python version

In pkgsrc this is called "PYTHON_SELF_CONFLICT". I would rather keep
the same name and put this in python.mk, as it is unrelated to
jrl-cmakemodules.

Seems go to me

- NEW_PYTHON_PREFIX for package which have been renamed with the
addition of a PKGTAG.python

Can't it be done by default (when USE_PYTHON is yes) ?
I'm not fan of such a temporary variable.

It can

- allow to build interfaces/ros-humanoid-msgs on ros > kinetic

This package is not present in ros > kinetic. So you will have issues
anyway with ros as a system package (and that's just a mistake that
this package is compiled for ros-melodic in robotpkg).

So maybe we can set PREFER = robotpkg for ros > kinetic ?

(otherwise, I get an error on building wip/prf-ros-controllers,
stating that no ros version is available at all)

Is the dependency on ros-humanoid-msgs really needed?
I would rather remove this package from robotpkg, as it is obsolete
(and maybe just convert it to a sysdep to support ros <= kinetic).

It looks like this is only for this:
https://github.com/pal-robotics/pal_msgs/blob/0.12.13/pal_walking_msgs/msg/WalkingStep.msg#L5

I don't know if it would be easy and a good idea to workaround that.

On Thursday 7 Nov 2019, at 13:39, Guilhem Saurel wrote:

In pkgsrc this is called "PYTHON_SELF_CONFLICT".

Done, as well as for QT.

- allow to build interfaces/ros-humanoid-msgs on ros > kinetic

I renamed the package to not pretend this is a ROS package anymore. On
ditributions with system ros <= kinetic, the system package is
used. Otherwise it defaults to robotpkg.

Thanks a lot !

I'll update this PR after a few tests.

Can't it be done by default (when USE_PYTHON is yes) ?
I'm not fan of such a temporary variable.

In fact, no: py-pinocchio must not conflict with pinocchio

Or we would have to check if another package named without PKGTAG.python currently exists or not

On Friday 8 Nov 2019, at 11:55, Guilhem Saurel wrote:

In fact, no: py-pinocchio must not conflict with pinocchio

Isn't this automatic conflict with py-less prefix valid just for hpp-*
packages? (meta-pkgs/hpp/Makefile.common)

Yes, this would work.

I was just using it also for py-eigenpy, and it could have been used for the recent modifications of catkin, and there are other candidates not yet pushed in wip:

https://github.com/nim65s/robotpkg-wip/commit/886b313f46ad82064d910f1f13fc7e5358285f24
https://github.com/nim65s/robotpkg-wip/commit/8897e2bd810b5ce434f81a1485f53e4752f69f47
https://github.com/nim65s/robotpkg-wip/commit/03f23c43236d4bd53fa3214cbe6369d224b88a11

We can set that by hand, as we are already doing, but I think this just copy-paste of a temporary code instead of a common option for the same thing. As you prefer :)

On Friday 8 Nov 2019, at 12:37, Guilhem Saurel wrote:

We can set that by hand, as we are already doing, but I think this
just copy-paste of a temporary code instead of a common option for
the same thing. As you prefer :)

OK, I pushed a PYTHON_NOTAG_CONFLICT :)

Hi,

I updated this PR, to use PYTHON_NOTAG_CONFLICT & PYTHON_SELF_CONFLICT.

Cheers,
Guilhem.

Pushed, thanks!

Thanks for the push :)

It looks like my commit for:

- suggest to build doc by default for HPP packages (I am not sure why this was not already the case)

has been lost at some point.

I am not sure if I forgot it in an history rewrite, or if you intentionaly dropped it ?

I cherry-picked it here: https://github.com/nim65s/robotpkg/commit/b6c9b3d45870ecbeb6821a28a88da38215e583fa

Best,
Guilhem.

On Wednesday 13 Nov 2019, at 14:47, Guilhem Saurel wrote:

I am not sure if I forgot it in an history rewrite, or if you
intentionaly dropped it ?

No, I did not drop it, it was not in your branch :)
Now it's pushed!

Thanks a lot !

Hello,

I think it was a good idea to provide the doc in the binary packages, but not to change their names, especially for hpp-fcl which is widely used, thanks to pinocchio.

Then, I suggest the following commits, to invert the option, ie. an option to disable the documentation, instead of an option to enable it. And while here, this option can be moved from meta-pkgs/hpp to devel/jrl-cmakemodules:
https://github.com/nim65s/robotpkg/commit/a1da6d10a6e21581253e6b6e2e3f888c7d09d717
https://github.com/nim65s/robotpkg/commit/3630a4cbd8d602de571f72015802dfd9e77ce03f

Thanks,
Guilhem.

The second had a typo, https://github.com/nim65s/robotpkg/commit/57312907870005b18a516b3080774ac529daeff5 is better :)

On Thursday 14 Nov 2019, at 08:43, Guilhem Saurel wrote:

I think it was a good idea to provide the doc in the binary
packages, but not to change their names, especially for hpp-fcl
which is widely used, thanks to pinocchio.

You mean the +doc string in the package name? (not the py- prefix,
right?) This was the only way we found to map the robotpkg option
semantics into deb binary packages. If you have a better idea, I'll be
happy to think about it. What is wrong with the name, though?

It is possible to build both binary packages, with and without the
option, if needed. A better alternative is to have a separate,
"doc-only" package.

Then, I suggest the following commits, to invert the option, ie. an
option to disable the documentation, instead of an option to enable
it.

In general, option names are meant to be as much consistent as
possible across robotpkg, so that you can set default choices with
PKG_DEFAULT_OPTIONS. Also, options are meant to be "positive",
ie. there are no "no*" options (double negations are always painful).

So a "nodoc" option would break those two rules, I'm not so enthusiastic
about it.

On Thursday 14 Nov 2019, at 12:43, Guilhem Saurel wrote:

Building both would also fix the issue I have right now with those
instructions in the wild, and yes, making a separate doc-only package
would be the best option. Is there already a nice way to do that in
robotpkg that I'm not aware of ?

You mean a way for building both or for the doc-only package?
For the former it's a matter of changing the bulk build configuration
but for the latter there is no helper of any sort. It would be trivial
if the packages would support it in their build system already
(i.e. configure + make doc works). Then you just create a package with
the many distfiles and as many CONFIGURE_DIRS + the right
BUILD_TARGET = doc (or BUILD_TARGET.dir = doc).

Another option is to always build the doc and drop the option :)
For the binary packages this does not add any dependency.

Ok, then I think for now we should either, at your preference:
- build both packages (with and without doc);
- or drop the option and always build the doc.

In a second time, I will work with the jrl-cmakemodules to get an option that install only the doc. It will also be the right time to uniform doxygen & sphinx options and use.

On Thursday 14 Nov 2019, at 16:37, Guilhem Saurel wrote:

Ok, then I think for now we should either, at your preference:
- build both packages (with and without doc);
- or drop the option and always build the doc.

All packages are now built with and without doc option.