Project

General

Profile

Pull request #264

Add OSG for gepetto-viewer

Added by Guilhem Saurel 13 days ago. Updated 3 days ago.

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

Description

Hi,

As previously discussed in #255, I
- added OSG v3.6
- added its Qt bindings
- configured gepetto-viewer & gepetto-viewer-corba to use those
- while here moved pythonqt here too and used it in Qt5 case.

This implied adding a patch to collada-dom, and adding sysdeps for qt5-svg & qt5-qtbase-private.
On this last point, I'm still not sure this is the best way to handle this "package".

I tested all of that on:
- 16.04 / py2 / qt4 / compilation & unittests only
- 18.04 / py2 / qt4 / use check
- 18.04 / py3 / qt4 / compilation & unittests only
- 18.04 / py3 / qt5 / use check
- arch / py3 / qt5 / use check

Cheers,
Guilhem.


Files

signature.asc (833 Bytes) signature.asc Guilhem Saurel, 2020-06-22 10:36
#1

Updated by Guilhem Saurel 12 days ago

I also added a new version of robots/{py-,}example-robot-data.

#2

Updated by Anthony Mallet 12 days ago

I see a number of issues:
  • graphics/py-pythonqt: it is not the same as mk/sysdep/py-qt{4,5}.mk right?
    Why PREFER = robotpkg by default?
  • graphics/osgqt is missing a PREFER default
  • In graphics/py-qt-gepetto-viewer, the "ifeq
    (qt4,${PKG_ALTERNATIVE.qt})" will not work: in gnu-make, the "if"
    trigger immediate evaluation of variables, and as this point
    PKG_ALTERNATIVE.qt is most likely not defined.
    (See
    https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html#index-ifeq_002c-expansion
    for immediate vs. deferred expansion)
    You should use a functional "$(if ...)" to get deferred expansion.
  • mk/sysdep/openscegraph should be (re)moved
#3

Updated by Guilhem Saurel 10 days ago

Hi,

Thanks for your inputs.

  • graphics/py-pythonqt: it is not the same as mk/sysdep/py-qt{4,5}.mk right?
    Why PREFER = robotpkg by default?

It i not. py-qt is a tool to create a Qt applications in python,
while py-pythonqt is a tool to embed and connect a python interpreter into an
existing C++ Qt application.

But actually, it looks like py-pythonqt is available, at least on 18.04, so I'll
check if this version works for us, and update this with the right PREFER.

  • graphics/osgqt is missing a PREFER default

Updated

Maybe that was working for me as I was manually setting PKG_ALTERNATIVE.qt for
my tests.

My issue here is that I need to conditionally include py-pythonqt, and I can't
find any way to to this with a functional "$(if ...)".

  • mk/sysdep/openscegraph should be (re)moved

Done.
I thought other packages would include it, but I can't find any.

#4

Updated by Anthony Mallet 10 days ago

On Monday 22 Jun 2020, at 10:36, Guilhem Saurel wrote:

My issue here is that I need to conditionally include py-pythonqt,
and I can't find any way to to this with a functional "$(if ...)".

That could be something like $(if ...,$(eval include ...)).
But dependencies cannot be added after alternative resolution, so this
would not work either.

The most obvious way to handle this is to have two distinct packages.
Is Qt4 support really required?

#5

Updated by Guilhem Saurel 10 days ago

If Qt5 works well in all our use cases, we don't need Qt4. I think it is worth a try.
If we have any issue, we will be able to fallback to distinct packages, but not before we find that it is required.

#6

Updated by Anthony Mallet 10 days ago

On Monday 22 Jun 2020, at 12:40, Guilhem Saurel wrote:

If Qt5 works well in all our use cases, we don't need Qt4. I think
it is worth a try. If we have any issue, we will be able to
fallback to distinct packages, but not before we find that it is
required.

OK

I did a preliminary merge with openscenegraph, to fix the small build
issues and deal with that first.

What about openthreads? You removed it because it's not required?

#7

Updated by Guilhem Saurel 10 days ago

openthreads is a component of openscenegraph, and I'm not sure if we really need it or not.

I see that you changed PREFER.openscenegraph for system. But the point of this PR is that, at least on 16.04, 18.04, 20.04 and Arch (and probably debian), the openscenegraph package provided by the system is not build with collada-dom, then the osg-dae plugin is missing, while we actually need it.

#8

Updated by Anthony Mallet 10 days ago

On Monday 22 Jun 2020, at 16:51, Guilhem Saurel wrote:

I see that you changed PREFER.openscenegraph for system. But the
point of this PR is that, at least on 16.04, 18.04, 20.04 and Arch
(and probably debian), the openscenegraph package provided by the
system is not build with collada-dom, then the osg-dae plugin is
missing, while we actually need it.

Ah. But #255 was about Qt5 :)
I guess it's not possible to just provide a package for just osg-dae?
(like osgqt)

#9

Updated by Guilhem Saurel 9 days ago

Ah, yes, the situation was so bad I was too lazy to summarize it, sorry x)

So basically, gepetto-viewer needs OSG, with Qt to draw windows and with DAE to load collada files.
Both Qt & DAE are plugins distributed inside OSG code base.

DAE was never provided with Debian or Ubuntu system packages, so we always had to distribute it in another way, basically by downloading OSG source code, and running "make && make install" in the DAE directory.

Qt4 was provided with Debian and Ubuntu, then in 2015 Debian switched to Qt5, and I was waiting for ubuntu to follow, so that we could get rid of Qt4.

But in 2018, OSG released its 3.6.0 version which removed the Qt plugin from their code base, to put it into another repository, so ubuntu just stopped providing Qt in 20.04.

So if we want OSG & DAE & Qt, we could
- use the system package for OSG & Qt until 20.04, plus compile DAE on the side
- use the system package for OSG from 20.04, plus compile Qt & DAE on the side

But this still wouldn't give us Qt5.

Plus 16.04 has OSG 3.2, 18.04 has 3.4 & 20.04 has 3.6, and I don't know if we can isolate one version of the DAE plugin and one version of the Qt plugin that would work on all those OSG versions.

So my guess is that it would be easier to provide OSG 3.6 everywhere and include DAE, plus provide Qt from its upstream new repository.

Maybe it's possible to make our wip/osg-dae package work again on Ubuntu 20.04 / OSG 3.6, but its source is a copy-paster from OSG 3.2 https://github.com/gepetto/osg-dae, so I'd prefer to drop it and switch back to the upstream. We could make another osg-dae package, providing the whole OSG source to robotpkg and building only the dae plugin, but I don't know if it would work in 16.04, and this would be more work for us than just provide directly OSG including the plugin.

#10

Updated by Guilhem Saurel 7 days ago

Hi,

From what I see, most packages are now building correctly, thanks !

We are just lacking boost-libs (and qmake & qt4-libs for Qt4) on 20.04. It is just an apt install away, is it not ?

But for the binary packages, at least on 18.04, robotpkg-qt{4,5}-osgqt are dependending on robotpkg-openscenegraph 3.6.5 | 3.6.5r1 ; while the current package is 3.6.5r3. Maybe a PKGREVISION bump was missed at some point ?

#11

Updated by Anthony Mallet 6 days ago

On Thursday 25 Jun 2020, at 08:08, Guilhem Saurel wrote:

We are just lacking boost-libs (and qmake & qt4-libs for Qt4)
on 20.04. It is just an apt install away, is it not ?

Not quite:

hydra64-ubuntu2004:/> apt search libqt4-dev
Sorting... Done
Full Text Search... Done

#12

Updated by Guilhem Saurel 5 days ago

I think I can install everything now, thanks !

But we still have some issues:

- "apt show -a robotpkg-qt5-osgqt" shows a 3.6.0 version in wip.

This version didn't actually exist upstream, it was created in our fork but it doesn't work at all: I was mislead by this: https://github.com/Gepetto/osgQt/releases.
Therefore, when running "robotpkg-py36-qt5-gepetto-viewer", I get an error because the last version of this pakage requires robotpkg-qt5-osgqt=3.5.7r2 and apt is not able to just do it. So we need to manually run "sudo apt install robotpkg-qt5-osgqt=3.5.7r2" before.

To fix this, can we remove that package from the wip apt repository ? Or do we have to increment an epoch number or something like that ?

- gepetto-viewer-corba is not working in python3. I don't know yet if this is a code or a packaging issue, I'll try to find this as soon as possible.

- pythonqt looks to build fine, but gepetto-viewer is not yet configured to use it. There is absolutely no hurry about that, I can take some time to do as many checks as possible before changing that, in order to avoid any other majore break of those packages :)

#13

Updated by Anthony Mallet 3 days ago

On Saturday 27 Jun 2020, at 10:36, Guilhem Saurel wrote:

To fix this, can we remove that package from the wip apt repository
?

That was a bit painful, but it should be cleanly removed from wip now!

Also available in: Atom PDF