Debian pkg builds, `DESTDIR`, and `3rdparty` sources

[zultron]

I'm trying to get Travis CI package builds working in this branch. The builds succeed, but only after a dirty hack.

Without the dirty hack, a make install DESTDIR=$PWD/debian/qml-module-qtquick-vcp (as dpkg-buildpackage does) errors out:

/usr/lib/x86_64-linux-gnu/qt5/bin/qmlplugindump -nonrelocatable Machinekit.HalRemote 1.0
    /[...]/QtQuickVcp/src/halremote/../../imports/
    > /[...]/QtQuickVcp/src/halremote/../../imports/Machinekit/HalRemote/plugins.qmltypes
QQmlComponent: Component is not ready

Rerunning with qmlplugindump -v reveals the real error:

file:///[...]/QtQuickVcp/imports/typelist.qml:14:1: \
    plugin cannot be loaded for module "Machinekit.HalRemote":
    Cannot load library /[...]/QtQuickVcp/imports/Machinekit/HalRemote/libmachinekithalremoteplugin.so:
    (libmachinetalk-pb2.so.1: cannot open shared object file: No such file or directory)

The problem is libmachinetalk-pb2.so.1 is installed under $DESTDIR, and qmlplugindump can't find it. The dirty hack (as seen in that branch) is to set $LD_LIBRARY_PATH. That actually builds working packages, but the dh_auto_install portion of the build log (where make install runs) is filled with (non-fatal) error messages:

ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded 
    (cannot open shared object file): ignored.

I did what I could to make $DESTDIR work in #214, but at this point I'm lost with the Qt build system. Having package builds isn't critical for me, so no big emergency. Thanks!

[machinekoder]

One option is to disable qmlplugindump: qmake QMLPLUGINDUMP=0

This skips generation of the plugin.qmltypes files.

[machinekoder]

The files are used for development, but not necessary for runtime execution.

[zultron]

Thanks, @machinekoder. Maybe it was past my bedtime when I opened this. Setting LD_LIBRARY_PATH caused the errors because its old value was clobbered. Instead, appending to the value works just fine.