QFINDTESTDATA uses __FILE__

[Ximin Luo]

Adrian Bunk:
> 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
> thanks
> 
> The problem is the following implementation in
> /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h:
> # 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
> directory:
>   http://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA
> 
> 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.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git