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

Ximin Luo infinity0 at debian.org
Mon Feb 11 05:39:00 GMT 2019


Sune Vuorela:
> On Sunday, February 10, 2019 10:05:00 PM CET you wrote: 
>> 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
> 
> But why not just record the build directory as part of the environment that 
> aren't allowed to change?  Just like all the other bits of the environment 
> that aren't allowed to change and still have reproducible builds?
> 

Ideally, we'd want as many people to rebuild the same hash as possible, so that the rest of the world (who we assume don't want to do these rebuilds) can see that 20 people built the same hash, rather than 5 people built 4 different hashes.

Also, this question also seems to contradict your earlier suggestion to "instead fix the programs that uses __FILE__ for something they shouldn't".

>> Note that __FILE__ was never intended to have any runtime meaning - tests
> 
> I'd like to see a source for that.
> 

C and C++ ISO standards documents both say something along the lines of:

Predefined macro names
1 The following macro names shall be defined by the implementation:
[..]
_ _ FILE _ _
The presumed name of the current source file (a character string literal).161
[..]

In the same way that this does not imply "and every time you invoke this macro you can expect a pink unicorn to fly out of your computer", equally this does not imply "you can assume that the name is a path that will exist after compilation".

Similarly, if we write a test like:

if ( (time() - to_epoch_seconds(__DATE__ __TIME__)) < 60 )

and run it 2 seconds (i.e. < 60) after we compile it, we generally do not expect this to work.

X

[1] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf

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





More information about the Reproducible-builds mailing list