Package Details: ros-melodic-qt-gui 0.4.2-2

Git Clone URL: https://aur.archlinux.org/ros-melodic-qt-gui.git (read-only, click to copy)
Package Base: ros-melodic-qt-gui
Description: ROS - qt_gui provides the infrastructure for an integrated graphical user interface based on Qt.
Upstream URL: https://wiki.ros.org/qt_gui
Licenses: BSD
Submitter: GPereira
Maintainer: None
Last Packager: bionade24
Votes: 2
Popularity: 0.000000
First Submitted: 2018-05-08 14:14 (UTC)
Last Updated: 2021-03-22 15:05 (UTC)

Latest Comments

gudwin commented on 2018-09-13 18:45 (UTC)

I am having trouble trying to build this package. First, the package python-rospkg is detected as not installed, and when trying to install it I get:

error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: python2-rospkg and python-rospkg are in conflict

When I try to delete python2-rospkg, yaourt warns me that it is required for a lot of other ros-melodic packages. I then edited PKGFILE and changed the dependency python-rospkg to python2-rospkg. This solved the first problem, but then I started to get:

CMake Error: The source directory "/tmp/yaourt-tmp-rgudwin/aur-ros-melodic-qt-gui/src/ros-melodic-qt-gui" does not appear to contain CMakeLists.txt.

In fact, the CMakeLists.txt is not at aur-ros-melodic-qt-gui/src/ros-melodic-qt-gui but actually in aur-ros-melodic-qt-gui/src/ros-melodic-qt-gui/qt_gui

I am not sure if the problem is at the PKGFILE, or in another place. This exactly same problem is appearing in 26 other packages from ros-melodic, all of them made available now on 08/Sept by GPereira. If the problem is not at the source code or at the PKGFILE, may it be due to some change in the behavior of cmake ? In all the cases where the problem appears, it is due to running cmake in a directory where there are only sub-directories, and the CMakeLists.txt are only on the subdirectories. The fact is that right now I have 26 ros-melodic packages with the exact same problem and I don't know if this was a problem introduced by the maintainer or by a possible change in cmake. Any clue ?