QFINDTESTDATA uses __FILE__
infinity0 at debian.org
Mon Nov 13 17:35:00 UTC 2017
> Control: reassign -1 qtbase5-dev
> Control: reassign 876917 qtbase5-dev
> Control: reassign 876933 qtbase5-dev
> Control: forcemerge -1 876917 876933
> Control: retitle -1 QFINDTESTDATA uses __FILE__
> Control: severity -1 normal
> Control: affects -1 src:karchive src:ki18n src:kcodecs src:kparts
> The problem is the following implementation in
> # define QFINDTESTDATA(basepath)\
> QTest::qFindTestData(basepath, __FILE__, __LINE__)
> With the patched gcc in the unstable reproducible builds setting
> __FILE__ to something other value, this does no longer find the
> test data.
> I do not really see any reason for blaming the users here for using
> a documented public Qt API for accesssing test data in the source
> I've added reproducible-builds at lists.alioth.debian.org to Cc for giving
> input what a reproducible and portable implementation might be for Qt.
Our patched dpkg tells GCC to map $PWD to "$srcpkg-$version" when expanding __FILE__. That is the source of the problem, because this path doesn't exist at test-time. You have the following options:
1. Unset BUILD_PATH_PREFIX_MAP. This is not great because things that use __FILE__ will become unreproducible.
2. Symlink "$srcpkg-$version" -> ".", so that the files can be accessed under the paths that __FILE__ was expanded to.
3. Set BUILD_PATH_PREFIX_MAP to map $PWD to . instead. You do this by doing `export BUILD_PATH_PREFIX_MAP=$BUILD_PATH_PREFIX_MAP:.=$PWD`, then the tests should work. This makes any other uses of __FILE__ in this package, inconsistent with other Debian packages (built with our patched dpkg).
(maybe there are other options)
I chose "$srcpkg-$version" because it provides some extra information, and allows one to distinguish files in different packages. Currently, dpkg-buildflags(1) sets -fdebug-prefix-map= to ".", so propsal (3) would actually be consistent with that. However I do think "$srcpkg-$version" is better because it's more informative. More generally, we don't want __FILE__-using tests to dictate how we should remap build paths *in general* in Debian.
The problem stems from the fact that we assume __FILE__ represents a build-time path and not a run-time path, so we rewrite it indiscriminately with BUILD_PATH_PREFIX_MAP.
This assumption is broken in the specific case where you have some source code that uses __FILE__, that are specifically only meant to be run at build-time, so that they are in fact run-time paths (that are also build-time paths). The assumption is fine in all other cases.
Therefore, the only solution to fix this problem, that also preserves reproducible builds, is to make those tests *not use __FILE__*. Or option (2), which makes the non-existent rewritten paths, into an actually-existing build-time path.
I am not "blaming the user", but pointing to the fact that __FILE__ is being used in a surprising way here, which is not good for reproducible builds. An analogy would be to write your program to execute something at time "__DATE__ + 30 seconds". This is obviously ridiculous, but works "by accident" if done inside a test case.
More information about the Reproducible-builds