Am 13.11.2017 um 20:15 schrieb Adrian Bunk:
On Sun, Nov 12, 2017 at 10:57:38AM +0100, Kai Pastor, DG0YT wrote:
Am 11.11.2017 um 17:18 schrieb Adrian Bunk:
I found what causes the problem:
The failing tests use the following for finding the path to test files:
QDir::addSearchPath(prefix,
QFileInfo(QString::fromUtf8(__FILE__)).dir().absoluteFilePath(prefix));
In unstable reproducible builds the build path is varied,
and gcc patched to accept setting __FILE__ to a fixed
(reproducible) location.
In other words, when Debian will start changing __FILE__ also on the
buildds this will become a FTBFS also there.
It is a pity that I immediately suspected the __FILE__ macro when I
studied this bug before, but didn't ask. I really couldn't imagine that
someone would tinker with such a commonly used feature, or at least one
would immediately notice a lot of breaking packages in the moment the
change was introduced. There is no mention of __FILE__ on
https://wiki.debian.org/ReproducibleBuilds/Howto...
Hm, I understand the benefit of reproducible builds. But does this really
need to extend to test binaries which do not get packaged? These tests need
to be as much stand-alone as possible and work out of the box in any context
(host OS, target OS).
I didn't find a recommendation how to solve the issue. I hope a custom macro
is okay.
Based on the discussion in #876901 [1] it is still unclear how this
should be resolved in general.
Semi-related, why aren't you using QFINDTESTDATA [2]?
Do be honest, I didn't know about QFINDTESTDATA, and it was not
available when we started (Qt 4.8). I looked for something like that
before answering yesterday and I think I saw QFINDTESTDATA at this time.
But a) the "Note:" section states some requirements for reliable
detection of testdata, and b) it is definitely considering multiple
locations where I explicitly want to use a single location. In addition,
c) now I didn't want to rely on anything which might use __FILE__ as
well. So it does not fit.
Kai.
