On Tue, Jul 28, 2020 at 12:15:25PM +0200, Peter Krempa wrote: > On Tue, Jul 28, 2020 at 10:33:52 +0200, Pavel Hrdina wrote: > > On Tue, Jul 28, 2020 at 10:09:42AM +0200, Peter Krempa wrote: > > [...] > > > > > Here I disagree, it also means that compilation should not fail. We do > > comments all the time to patch series that every single commit should > > compile correctly on it's own within the series. > > Doing a 'return 0' is not compiling code correctly. The idea of > requirements to bulild cleanly is that you can test the code. > > In this case we need to observe it from a different angle though. > > In reality an incomplete build is a failed build regardless of what the > return value of the build system is. And that is important here. The > main reason for the build system is to build everything so the only > success is when everything is built. > > If you don't have the resulting binary it's impossible to test the code > or do anything else. > > What would be even worse is to get a compiled binary that e.g. doesn't > have the dependencies installed (such as RNG schemas, cpu XML docs and > such) and fails in magic ways. At that point you can't be sure whether > it's the bug you are trying to locate or just plainly broken build > which the build system lied to you that it's complete. Obviously this would be a big issue if it would randomly fail because of some missing files that are not yet compiled. I have no objection here. If your only use-case is to run binaries during git bisect then yes having not-complete build when build system returns 0 is not correct. I'm just saying there might be some other use-cases for git bisect where having incomplete build is not an issue and we should not dismiss these use-case. Pavel
Attachment:
signature.asc
Description: PGP signature
