[libvirt PATCH 000/351] port libvirt to Meson build system

Pavel Hrdina phrdina at redhat.com
Tue Jul 28 11:34:17 UTC 2020

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200728/c13d7924/attachment-0001.sig>

More information about the libvir-list mailing list