On Thu, Jul 16, 2020 at 01:59:00PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 16, 2020 at 11:53:56AM +0200, Pavel Hrdina wrote:
> > So I was finally able to produce the patches to port libvirt to Meson.
> > Obviously, it is a lot of changes. It might look that some of the
> > patches could be squashed together but I would rather have it as
> > separated as possible to make the review not that difficult.
> >
> > Once we are done with review I suggest to squash all patches to single
> > patch as it doesn't make sense to keep them separated as it will not be
> > possible to build complete libvirt code by any of the build systems.
> > Trying to achieve that would be even more challenging and the review
> > would me more difficult.
> >
> > The reasoning behind taking this approach is to have 1:1 conversion from
> > autotools to Meson where each patch removes that part from autotools. It
> > serves as a check that nothing is skipped and to make sure that the
> > conversion is complete.
>
> Can you clarify a bit more what the expected behaviour is for the
> intermediate patches in the series ? eg if I was to "git bisect"
> across this series, how much will work vs break ? I'm not fussed
> if stuff like "make dist" breaks, but does the basic "make" and
> "make check" (or meson equivalent) work ? I'm also not fussed if
> the intermediate stages require running *both* make and meson
> as separate commands in order to full build.
The way how the patches are done will mean that autotools will not work
or randomly fail and things like that. I was not basically paying any
attention to not breaking autotools. Some of the bits removed from
autotools throughout the series will definitely break even simple make
invocation.
Running both to fully build libvirt would be IMHO insane and complicated
so I was not even considering that option.
I tried it and the current state is that make will break with patch
[PATCH 002/351] meson: remove automake specific directives
it complains a lot about incompatible endif reminder where deleted the
else branch of the if-else-endif structure.
Invoking meson will work since patch:
[PATCH 010/351] meson: introduce meson build files
But it will not do any actual build until patch:
[PATCH 129/351] meson: src: build dtrace files
I also tried running git rebase with:
--exec='git clean -dfx && meson build && ninja -C build'
and discovered that I would have to move patch
[PATCH 080/351] meson: add driver_remote build option
before patch that requires 'driver_remote' option:
[PATCH 058/351] meson: add libssh build dependency
otherwise running meson between patches 58 and 80 will fail.
> Personally I'd really like to avoid squashing them, because splitting
> up big patches is not merely to benefit the initial pre-merge review,
> but to also benefit people who need to debug stuff that's already
> merged and understand the scope of the intended change. So being able
> to look back at the changes in isolation after commit is still a big
> plus point.
I would like to avoid squashing the patches as well and in most cases I
would object to it as well. I only suggested that to not break git
bisect.
If we don't care about git bisect and the fact that we would not be able
to build libvirt correctly within these patches I'm OK with pushing it
without squashing.
Pavel
Attachment:
signature.asc
Description: PGP signature
