A while ago we had a discussion about building k3b. The configuration output declared not being able to find the dbus headers.
I can resolve the configuration error by building dbus-tqt to install in /usr rather than /opt/trinity.
Likewise, I eliminate the same configuration errors with kmplayer.
The Trinity dbus-tqt package is not a full package but only replaces four header files and a lib file.
Are the Trinity replacement dbus files intended to overwrite the stock files installed in /usr by the distro?
Does dbus-1.0 get used by Qt4 apps or is there a different mechanism? I'm unclear how this all relates.
Darrell
On 04/13/2012 05:43 PM, Darrell Anderson wrote:
A while ago we had a discussion about building k3b. The configuration output declared not being able to find the dbus headers.
Yes, I think I posted that or was involved in the discussion. Why can't we make k3b find the dbus headers if we keep them in /opt/trinity? Couldn't we just edit the CMake files ConfigureChecks.cmake checks and have them check in the normal prefixes? /opt/trinity, /opt/tde, /usr? Or why not have the cmake files create and source a file similar to /etc/profile.d/trinity.sh.? You could use a check to test for the actual trinity.sh, use it if present, else use one based on the chosen prefix at the start of the build with tqt3?
export TDEDIR=/opt/trinity export TDEDIRS=$TDEDIR export PATH=$PATH:$TDEDIR/bin export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$TDEDIR/lib/pkgconfig if [ ! -z $XDG_DATA_DIRS ]; then export XDG_DATA_DIRS=$XDG_DATA_DIRS:$TDEDIR/share else export XDG_DATA_DIRS=$TDEDIR/share fi if [ ! -z $XDG_CONFIG_DIRS ]; then export XDG_CONFIG_DIRS=$XDG_CONFIG_DIRS:$TDEDIR/etc/xdg else export XDG_CONFIG_DIRS=$TDEDIR/etc/xdg
I can resolve the configuration error by building dbus-tqt to install in /usr rather than /opt/trinity.
Likewise, I eliminate the same configuration errors with kmplayer.
The Trinity dbus-tqt package is not a full package but only replaces four header files and a lib file.
Are the Trinity replacement dbus files intended to overwrite the stock files installed in /usr by the distro?
On Arch - amazingly - NO. Arch seems to preface it's dbus-1/dbus headers with 'dbus-' thus avoiding the conflict. The dbus-tqt files that would conflict would be:
pacman -Qplq tde-dbus-tqt-3.5.14_dev-8-i686.pkg.tar.xz /opt/ /opt/trinity/ /opt/trinity/include/ /opt/trinity/include/dbus-1.0/ /opt/trinity/include/dbus-1.0/dbus/ /opt/trinity/include/dbus-1.0/dbus/connection.h /opt/trinity/include/dbus-1.0/dbus/dbus-qt.h /opt/trinity/include/dbus-1.0/dbus/message.h /opt/trinity/include/dbus-1.0/dbus/server.h /opt/trinity/lib/ /opt/trinity/lib/libdbus-tqt-1.la /opt/trinity/lib/libdbus-tqt-1.so /opt/trinity/lib/libdbus-tqt-1.so.0 /opt/trinity/lib/libdbus-tqt-1.so.0.0.0 /opt/trinity/lib/pkgconfig/ /opt/trinity/lib/pkgconfig/dbus-tqt.pc
Does dbus-1.0 get used by Qt4 apps or is there a different mechanism? I'm unclear how this all relates.
Dunno??
Darrell
Darrell,
Archlinux - which is bleeding edge as you say has the following included in its dbus-core package. As long as Arch keep the 'dbus-' prefix on the dbus-1/dbus headers, no conflict here:
21:30 nirvana:~> pacman -Qlq dbus-core /etc/ /etc/dbus-1/ /etc/dbus-1/session.conf /etc/dbus-1/session.d/ /etc/dbus-1/session.d/.keep /etc/dbus-1/system.conf /etc/dbus-1/system.d/ /etc/dbus-1/system.d/.keep /etc/rc.d/ /etc/rc.d/dbus /lib/ /lib/systemd/ /lib/systemd/system/ /lib/systemd/system/dbus.service /lib/systemd/system/dbus.socket /lib/systemd/system/dbus.target.wants/ /lib/systemd/system/dbus.target.wants/dbus.socket /lib/systemd/system/multi-user.target.wants/ /lib/systemd/system/multi-user.target.wants/dbus.service /lib/systemd/system/sockets.target.wants/ /lib/systemd/system/sockets.target.wants/dbus.socket /usr/ /usr/bin/ /usr/bin/dbus-cleanup-sockets /usr/bin/dbus-daemon /usr/bin/dbus-monitor /usr/bin/dbus-send /usr/bin/dbus-uuidgen /usr/include/ /usr/include/dbus-1.0/ /usr/include/dbus-1.0/dbus/ /usr/include/dbus-1.0/dbus/dbus-address.h /usr/include/dbus-1.0/dbus/dbus-bus.h /usr/include/dbus-1.0/dbus/dbus-connection.h /usr/include/dbus-1.0/dbus/dbus-errors.h /usr/include/dbus-1.0/dbus/dbus-macros.h /usr/include/dbus-1.0/dbus/dbus-memory.h /usr/include/dbus-1.0/dbus/dbus-message.h /usr/include/dbus-1.0/dbus/dbus-misc.h /usr/include/dbus-1.0/dbus/dbus-pending-call.h /usr/include/dbus-1.0/dbus/dbus-protocol.h /usr/include/dbus-1.0/dbus/dbus-server.h /usr/include/dbus-1.0/dbus/dbus-shared.h /usr/include/dbus-1.0/dbus/dbus-signature.h /usr/include/dbus-1.0/dbus/dbus-threads.h /usr/include/dbus-1.0/dbus/dbus-types.h /usr/include/dbus-1.0/dbus/dbus.h /usr/lib/ /usr/lib/dbus-1.0/ /usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/lib/dbus-1.0/include/ /usr/lib/dbus-1.0/include/dbus/ /usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h /usr/lib/dbus-1.0/test/ /usr/lib/libdbus-1.so /usr/lib/libdbus-1.so.3 /usr/lib/libdbus-1.so.3.5.8 /usr/lib/pkgconfig/ /usr/lib/pkgconfig/dbus-1.pc /usr/share/ /usr/share/dbus-1/ /usr/share/dbus-1/services/ /usr/share/dbus-1/services/.keep /usr/share/dbus-1/system-services/ /usr/share/dbus-1/system-services/.keep /usr/share/doc/ /usr/share/doc/dbus/ /usr/share/doc/dbus/dbus-faq.html /usr/share/doc/dbus/dbus-specification.html /usr/share/doc/dbus/dbus-test-plan.html /usr/share/doc/dbus/dbus-tutorial.html /usr/share/doc/dbus/diagram.png /usr/share/doc/dbus/diagram.svg /usr/share/doc/dbus/system-activation.txt /usr/share/licenses/ /usr/share/licenses/dbus-core/ /usr/share/licenses/dbus-core/COPYING /usr/share/man/ /usr/share/man/man1/ /usr/share/man/man1/dbus-cleanup-sockets.1.gz /usr/share/man/man1/dbus-daemon.1.gz /usr/share/man/man1/dbus-monitor.1.gz /usr/share/man/man1/dbus-send.1.gz /usr/share/man/man1/dbus-uuidgen.1.gz /var/ /var/lib/ /var/lib/dbus/ /var/run/ /var/run/dbus/
A while ago we had a discussion about building k3b. The
configuration output declared not being able to find the dbus headers.
Yes, I think I posted that or was involved in the discussion. Why can't we make k3b find the dbus headers if we keep them in /opt/trinity? Couldn't we just edit the CMake files ConfigureChecks.cmake checks and have them check in the normal prefixes? /opt/trinity, /opt/tde, /usr? Or why not have the cmake files create and source a file similar to /etc/profile.d/trinity.sh.? You could use a check to test for the actual trinity.sh, use it if present, else use one based on the chosen prefix at the start of the build with tqt3?
I have since learned that the Trinity dbus-tqt package is a full dbus package replacement (there are only a few files in the package). The reason for the additional files in /usr/include/dbus-1.0/dbus is from other dbus related packages, such as dbus-glib and dbus-python.
Installing the modified dbus-tqt package to /usr bothers me because I don't know the effect on other distro packages that built against the original dbus package, which is being replaced by the tqt layer. Those distro packages know nothing about the tqt layer.
The alternative is installing dbus-tqt to any place other than /usr means various Trinity packages don't build correctly.
I agree the build configuration and make files should be modified to use the Trinity version of the dbus headers so the stock distro system remains unaffected. Only Trinity packages need to adjust to the modified dbus headers.
I don't know how to make those modifications.
With kmplayer I found a work-around of using --with-extra-includes. That work-around fails with k3b.
Perhaps installing dbus-tqt to /usr has no effect on distro packages, but nobody answers these questions.
Darrell
-
Darrell Anderson -
David C. Rankin