Bug#876901: QFINDTESTDATA uses __FILE__

Ximin Luo infinity0 at debian.org
Mon Nov 13 23:44:00 UTC 2017

Pino Toscano:
> [..]
> This is not an annoyance, it is the crux of the problem!  __FILE__ is
> something standard, with a very well defined behaviour, upon which
> people rely on: you cannot trash it from one day to another like this,
> saying "too bad" to all its users, even those using it appropriately.
> It does not simply work.
>> but the point is that the previous use does not generalise well.
> To be honest: I already said multiple times that abuses of __FILE__
> *must* be fixed.  However, there are valid use cases, and in this case
> the only generalization is done by you, who declared __FILE__ as
> "absolutely BAD".

It's an objective fact that tests using __FILE__ are unable to be generalised to be run outside of the build.

As Lisandro said in the other comment, "We do *not* want to run the tests outside the build."

As I said in my previous comment, "For example if you try a program that works fine when compiled natively but doesn't work when cross-compiled, that is a failure to generalise and one can either say "not supported, stop breaking us" or one can try to generalise one's program."

It's also an objective fact that we're encouraging post-install tests such as autopkgtest. Pre-install tests (dh_auto_test) are good because of a tighter feedback loop, post-install tests are good because they are more accurate, they test directly what users install. For example, that installation paths were actually correct.

>> It's not a sledgehammer solution, it's tweakable and we can try to
>> use its flexibility to un-break your tests.
> No, it *is* a sledgehammer solution, since you are not even checking
> what __FILE__ is used for, and thus blindly changing it without any
> pre-research on its effect.  Again, this is not the correct approach
> to fix the issue at hand.

There are quite a lot of packages that use __FILE__ so forgive me for not checking every single use-case of it.

My patch fixes 1800 packages, and the amount of extra FTBFS it caused (such as this) is a blip in the stats, and a very minor one at that - failing tests, because a file was not found. Give me a break.

(Yes it is RC, but technically it is minor and very easy to fix, but you're denying us the fix because you seem to feel that the standards are on your side. Well let's take a look at the standards:

- https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
  "This is the path by which the preprocessor opened the file, not the short name specified in ‘#include’ or as the input file name argument. "
  Nope, no guarantee of absolute path here. The preprocesser could have cd'd to a random directory and then opened the file by a relative path.

- https://msdn.microsoft.com/en-us/library/027c4t2s.aspx
  "__FILE__ The name of the current source file. __FILE__ expands to a character string literal. To ensure that the full path to the file is displayed, use /FC (Full Path of Source Code File in Diagnostics). This macro is always defined."
  No guarantee of absolute path here either. It even says to guarantee full path you need to pass a specific compiler switch.

So, get off your high horse about "standards" and "well-defined". I really didn't want to pull this card because I think it is missing the point, but you seem to hold onto it with particular religious fervour.)

>> So, what do you think of this alternate solution, that I suggested:
> Any of your solutions get a big, fat, and giant nope.

You're forcing us to choose between fixing 1800 packages minus your QT packages, or fixing nothing. I ask you to be slightly less absolutist. The solution I proposed is 1-line and should cause basically no disruption to anything else.

>> If this isn't suitable to you, how else do you suppose we should try
>> to make builds independent of (i.e. not embed) the build path?
>> Suggestions are welcome.
> I already wrote it in my email, and I repeat it again:
> | No, the solution is:
> | a) *not* break what __FILE__ means
> | b) remove the misuses of __FILE__ in packages (not the case of

This will require us to patch hundreds of packages, and isn't realistic. Please, you try sending hundreds of patches, then I will take your "solution" more seriously.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

More information about the Reproducible-builds mailing list