Bug#876901: QFINDTESTDATA uses __FILE__
pino at debian.org
Wed Nov 15 18:44:50 UTC 2017
In data mercoledì 15 novembre 2017 12:09:00 CET, Ximin Luo ha scritto:
> Lisandro Damián Nicanor Pérez Meyer:
> > [..]
> > Xi: you also mentioned that having to file hundreds of patchs seems
> > impossible. Well, it seems so, but it is actually not that necessary. Please
> > allow me to explain the idea.
> Thanks for being less inflammatory than Pino.
Flame that you started, mind you.
> I agree that eventually all projects should move away from using
Again, why? Just because __FILE__ gives results that break
reproducibility does not mean that it is wrong/bad -- the topic of this
bug is exactly one of the cases where it *does* make sense to use
> This BUILD_PATH_PREFIX_MAP variable is only a stepping stone to that,
> just like SOURCE_DATE_EPOCH was a stepping stone to less projects
> using __DATE__ and __TIME__. It allows people to see the obvious
> benefit of a reproducible build, by actually achieving a large amount
> of reproductions, today. We did not need to file mass bug reports for
> __DATE__ and __TIME__ with SOURCE_DATE_EPOCH.
Again: comparing with __DATE__ and __TIME__ makes no sense, since they
were used in 99+% of the cases only for display purposes. OTOH, this
thread shows __FILE__ it is not used (only) for that.
> You're implying that QT's use of __FILE__ for tests, as being
> discussed in this thread, is a "good use case"
Exactly, it *is*.
> That's not how I see it. As I pointed out various times already, the
> use of __FILE__ here is *also not appropriate*. You can consider
> these emails from me now, as "documenting/blogging" about "bad use
OK, sure, we agree to disagree. But ...
> In summary: in no document or standard, does it guarantee or imply
> that __FILE__ can be taken to represent a real filesystem path.
> Applications relying on this behaviour are broken and should not be
> upset when things don't work. As documented in multiple places,
> __FILE__ only has a very loose meaning, my patch fits within this
> loose meaning, and it is intended mostly for error messages.
... this is your own interpretation. Even if __FILE__ has a loose
meaning, you are still changing that small bit of meaning it has,
without even thinking twice. Also, where it is written that __FILE__
is "only for error messages"?
> The BUILD_PATH_PREFIX_MAP variable works around a lot of "bad use
> cases", but it doesn't cover this particular case. Some minor tweaks
> are needed to cover it, and I suggested them already.
So this is not a solution, but low quality workaround.
> But you guys continue to push the position "we're doing nothing
> wrong, it's other people doing stuff wrong, go talk to them instead".
Let's flip this: you continue to push the position "everybody using
__FILE__ is wrong, I won't listen to anybody".
> I'm sorry but it's not a convincing position for me to agree with.
Neither is yours, sorry.
> At the end of the day, all of these cases, including yours, ought to
> be fixed to not use __FILE__ at all.
Again, we agree to disagree.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Reproducible-builds