Project

General

Profile

Actions

Pull request #207

closed

Update Pinocchio, omniORB, gepetto-viewer-corba & hpp-corbaserver

Added by Guilhem Saurel almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Repository URL:
Repository branch:

Description

Hello,

Pinocchio v2.1.3 is available here: https://github.com/nim65s/robotpkg/commit/8928f0e4dd5df3d132ac752922eb9ef99c8275b7

As omniORB & omniORBpy are available on Ubuntu only for python2 (they both have files in ${PYTHON_SITELIB}), I suggest to add a PKGTAG.python to their name, to provide a Python 3 binary version for Ubuntu. Otherwise, most of gepetto-viewer & hpp would not be usable in Python 3, even if they compile and install correctly.
The patch is here: https://github.com/nim65s/robotpkg/commit/0730604de8f6510f62177c6b120a5029e8a0ea37

Also, we found issues with the new omniidl python backend that exposes docstrings: docstrings are not writable in our case on Python 2, so here are patches for:
- gepetto-viewer-corba: https://github.com/nim65s/robotpkg/commit/32434c7f3e47d3e162544b88a3cacf939699fc80
- hpp-corbaserver: https://github.com/nim65s/robotpkg/commit/d5ba00c2575c7542091e5ceddb627eb0fbbf1a66

Then, while testing that, I also found that omniORB 4.2.2 on Python 3 was not building on Arch, probably because of Python 3.7 related issue, so I also suggest to update to 4.2.3:

- omniORB: https://github.com/nim65s/robotpkg/commit/c22a520887e79540309830213c42b279f113aa39
- omniORBpy: https://github.com/nim65s/robotpkg/commit/a7212cbf7bb496db5bd2ede01d59ecdf18ac306e

For all of those commits, build and unit test of most gepetto packages have been checked in 14.04, 16.04, 18.08, fedora 27, fedora 28 & arch, both in python 2 & python 3, with ubuntu on Qt 4 and fedora / arch on Qt 5.
Integration tests have also been run in 16.04, 18.04 & arch, also in python 2 & python 3, with ubuntu on Qt 4 & arch on Qt 5.

Still, I was trying to set PREFER.omniORB = robotpkg when we are on ubuntu and on python 3, so I tried in 0730604de8f6510f62177c6b120a5029e8a0ea37 with :

ifeq (Ubuntu,${OPSYS})
  ifneq (,$(filter python34 python35 python36 python37,${DEPEND_USE}))
    PREFER.omniORB?=    robotpkg
  endif
endif

But it doesn't seem to work, as I had to add PRFER.omniORB=robotpkg to my robotpkg.conf.

I think that as omniORB & omniORBpy were on PREFER=system, the changes I made should not break other packages that depends on them, but I did not check that further for now.

Cheers,
Guilhem.

Actions #1

Updated by Guilhem Saurel almost 5 years ago

  • Tracker changed from Bug to Pull request
Actions #2

Updated by Guilhem Saurel almost 5 years ago

I also had to add a patch to omniORB for python 3, as explained here: http://www.omniorb-support.com/pipermail/omniorb-list/2019-May/032063.html

Actions #4

Updated by Anthony Mallet almost 5 years ago

On Friday 10 May 2019, at 11:08, Guilhem Saurel wrote:

As omniORB & omniORBpy are available on Ubuntu only for python2

AFAICT, omniidl uses python3 on Ubuntu 18:
% head -1 /usr/bin/omniidl
#!/usr/bin/python3

(they both have files in ${PYTHON_SITELIB}), I suggest to add a
PKGTAG.python to their name, to provide a Python 3 binary version

At least for omniORB, this is not a good idea: the python dependency
is internal and should not be exposed to other packages (otherwise it
would impose to use the same python version as omniORB for all
dependent packages). And according to the history of omniORBpy in
robotpkg, the same applies, although it's less clear to me.

What should be tested properly is "can omniidl generate python code
for any version, when it is itself built with python2 or python3".

Another strategy could be to force python3 for omniORB{,py}, as
python2 will disappear soon anyway... Then I guess that the generated
code must work for any python version.

Actions #5

Updated by Anthony Mallet almost 5 years ago

Still, I was trying to set PREFER.omniORB = robotpkg when we are on
ubuntu and on python 3, so I tried in
0730604de8f6510f62177c6b120a5029e8a0ea37 with :

 ifeq
> (Ubuntu,${OPSYS})
>   ifneq (,$(filter python34 python35 python36 python37,${DEPEND_USE}))
>     PREFER.omniORB?=    robotpkg
>   endif
> endif
> 

Since omniorb{,py} are both available on ubuntu, I would not recommend
to use PREFER = robotpkg by default. This is always confusing and
error prone to have local packages when system ones are present ...
Of course you can set it in your robotpkg.conf

But it doesn't seem to work, as I had to add PRFER.omniORB=robotpkg to
my robotpkg.conf.

No, probably because at the time this file is included, the python
dependency has not been parsed yet. Something that would work would
be :
PREFER.omniORB?= $(if $(filter pythonXX,${DEPEND_USE}),robotpkg,system)

Contrary to "ifeq" statements that are eval'ed immediately, make
$(if ..) function is eval'ed like variables, when they are expanded.

Actions #6

Updated by Guilhem Saurel almost 5 years ago

AFAICT, omniidl uses python3 on Ubuntu 18:
% head -1 /usr/bin/omniidl
#!/usr/bin/python3

Right now, if I use ubuntu 18.04's omniORB / omniORBpy, I can compile py36-qt4-gepetto-viewer-corba. Omniidl, which is used to generate bindings, is a software written in python, and internally uses python 3, yes, but it could be written in any other langage and this would not make any difference for the generated files.

But then, we need to use those bindings. And inside those, we can find:

import omniORB

And on Ubuntu 18.04, dpkg -L python-omniorb shows stuff only in /usr/lib/python2.7/dist-packages/omniORB. And Ubuntu 18.04 doesn't provide a python3-omniorb package.

So when I try to use py36-qt4-gepetto-viewer-corba, I get the following error:

ModuleNotFoundError: No module named 'omniORB'

And building robotpkg's omniORBpy with python3 correctly installs files in a PYTHON_SITELIB for python 3.

Maybe I should have started by explaining that I got this error.

Actions #7

Updated by Anthony Mallet almost 5 years ago

On Monday 13 May 2019, at 11:58, Guilhem Saurel wrote:

But then, we need to use those bindings. And inside those, we can
find:

 import omniORB 

OK, now I understand.

I pushed an intermediate solution: omniORB does not expose python, so
it's not py-prefixed. Only py-omniORBpy needs it.
I tested it quickly on ubutu 18.04, it seems OK.

Actions #8

Updated by Guilhem Saurel almost 5 years ago

Yes, omniORBpy is enough. Thanks !

Actions #9

Updated by Guilhem Saurel over 4 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF