Buildd-setup faffing around with __FILE__ breaks my unit tests.

Ximin Luo infinity0 at debian.org
Sun Feb 10 21:05:00 GMT 2019


Sune Vuorela:
> On Sunday, February 10, 2019 8:38:00 PM CET Ximin Luo wrote:
>> Yes, pass the source dir in through the build system "somehow", there are
>> lots of possible ways you can do this, and this is what every other test
>> runner does. A command-line argument or environment variable would be
>> simplest.
> 
> So what you are saying is rewrite all test cases or build systems for tests 
> using QFINDTESTDATA?  I don't think that's a feasible approach.
> 
> Also note that the way QFINDTESTDATA is implemented doesn't require support 
> from the build system at all. Only the compiler. So quite some 
> rearchitechturing  of lots of existing tests are needed. 
> 
> I could of course try to get something into Qt like
> 
> #ifndef QTEST_SOURCE_LOCATION
> #define QTEST_SOURCE_LOCATION __FILE__
> #endif
> 
> then redo QTESTDATA to 
> #define QTESTDATA(filepath) ..... (filepath, QTEST_SOURCE_LOCATION) 
> 
> and then go thru all the unit tests in the world and for the cmake based tests 
> add
> 
> target_compile_definitions(testname PRIVATE -DQTEST_SOURCE_LOCATION="$
> {CMAKE_CURRENT_SOURCE_DIR}") 
> 
> and something similar for all the qmake based builds. and for the other build 
> systems. 
> 

There are some other alternatives. For example, the QFINDTESTDATA macro could be redefined to read an envvar/the cwd, and the test runner could set this envvar / the cwd.

It is not necessary to pass arguments explicitly down the call stack all the time. Sometimes this is useful but as you see in your above example it can get unwieldy. Even purely-functional programming languages like Haskell have various concepts designed to act as "implicit arguments" that avoid having to pass arguments explicitly.

> I still don't think I have understood why modifying the existing behaviour of 
> __FILE__ is actually needed.
> 

To fix this in other projects, we would have to patch all uses of __FILE__ to something like strip_prefix(PREFIX, __FILE__), pass in PREFIX from the buildsystem and make sure strip_prefix is defined somewhere, maybe in some glibc header. In other words, something very what I'm suggesting QT does right now.

But since there are more direct uses of __FILE__, it is much less effort to just set -ffile-prefix-map rather than do these patches everywhere.

Note that __FILE__ was never intended to have any runtime meaning - tests that assume this meaning only "accidentally work" and would break if e.g. used in a end-user post-install test (e.g. autopkgtest) and executed with the source files installed into a location different from the original build.

> 
> /Sune
>  - who by the way cleaned most of Qt for the __DATE__ and __TIME__ macros.
> 

Thanks, sorry for having a go at you. Though we do have SOURCE_DATE_EPOCH these days, so using __DATE__ and __TIME__ are actually not so bad now.

X

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



More information about the Reproducible-builds mailing list