On lunes, 13 de noviembre de 2017 23:44:00 -03 Ximin Luo wrote: > 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.
No, it's by design. > 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." Sorry, but I do not buy that comparison. I do understan the cross compilation effort and the reproducibility one, but this test are designed and ment to be run at build time, they are unti tests for a purpose. > 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. And the test this change are breaking are not ment to be run as post-install tests. > >> 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. But then if we accept a work around as you porpose it becomes a delta from upstream. There is too much in our plates to be forced to keep a delta. > (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. Nobody asked for full paths. > - 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. And you are forcing us to keep a delta from upstream. If a unit test now fails upstream will look at it and the first thing they will say is "Fix your macros". They have done so in the past and they where right. > >> 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 > > | > > | QFINDTESTDATA) > > 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. Sorry, it is not realistic to force us to have a delta from upstream for no direct gain. -- http://www.phdcomics.com/comics/archive.php?comicid=56 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
