Re: [Media Summit] Finalizing the v4l-utils conversion to meson

Laurent Pinchart
2022-09-08T21:02:32Z

On Thu, Sep 08, 2022 at 11:51:06AM +0300, Laurent Pinchart wrote:
> On Thu, Sep 08, 2022 at 10:41:21AM +0200, Hans Verkuil wrote:
> > On 29/08/2022 03:34, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > This mail (and hopefully mail thread) aims to prepare for the Media
> > > Summit 2022 discussion about finalizing the conversion of v4l-utils to
> > > meson.
> > >
> > > The original port of v4l-utils to meson was done by Ariel D'Alessandro
> > > (big thanks for that !) and posted to the linux-media mailing list in
> > > April 2022 ([1]). Another RFC version followed ([2]), and the series
> > > then graduated to non-RFC ([3]) with new versions following ([4], [5]
> > > and [6]) until v5 ([7]) in May 2021. I believe it is time to decide if
> > > we want to move to a more modern build system or stay for the foreseable
> > > future in the past (this statement should indicate my opinion on the
> > > subject :-)).
> > >
> > > I maintain a branch with the meson integration that I keep rebasing on
> > > top of the v4l-utils master branch. You can find it at
> > >
> > > git://linuxtv.org/pinchartl/v4l-utils.git meson
> > >
> > > I have also just posted the latest version of the integration patches in
> > > a v6 ([8]).
> > >
> > > I have been using the meson integration for about 2 years now, and it
> > > has provided me with a much smoother experience than autoconf, both for
> > > native builds and cross builds. Long gone are the day where I had to
> > > fight autoconf and hack various Makefile.am to comment out pieces of the
> > > tree that would fail to compile properly and wouldn't want to get
> > > disabled through autoconf. These issues are most likely due to
> > > shortcomings in the autoconf usage in v4l-utils than problems with
> > > autoconf and automake themselves, but I quickly gave up on trying to fix
> > > that as meson just worked out of the box as intended.
> > >
> > > This being said, I won't pretend that the current implementation would
> > > work perfectly for everybody. I twould thus like to get feedback on how
> > > to move forward.
> > >
> > > 1. Is there a general agreement that replacing autoconf is a good idea,
> > > provided that any technical issue in the proposed meson implementation
> > > (if any) can be fixed ? Or would it require fighting ophidiophobia and
> > > other non-technical issues that would make it a lost battle from the
> > > start ?
> >
> > I did a quick check to see if it handles setting the date/build/sha
> > correctly for some of the utilities I maintain (i.e. v4l2/cec-compliance
> > needs to show the SHA of the commit it was built from), and that seems to
> > be OK.
> >
> > Given the fact that it is better at cross-compiling I have no objection
> > to switching over.
> >
> > It should be a complete switch, though. It's one or the other, not both.
>
> I agree, maintaining both would increase the maintenance burden and
> guarantee that bugs would creep in over time.
>
> > If we do this, then I think we should try and prevent adding new libs
> > or applications for a bit (one kernel cycle?) to make it easy to revert
> > if we run into unexpected problems. And also bump the version number
> > and ask Gregor to check that it builds fine for debian.
>
> I'm fine with that. Maintaining a meson branch on top of v4l-utils has
> been relatively low effort, there were occasional additions to
> v4l-utils, but they were easy to handle. I would think that reverting
> would be equally easy, if needed.

Also, if we already have a consensus among the audience of the media
summit, we can remove this discussion point from the agenda and use the
time for other topics.

Should I prepare a new version of the patches, removing
autoconf/automake support on top ?

> I will also be there to help addressing any bug in the build system.
>
> > > 2. What are the technical issues that still need to be solved (if any)
> > > to replace autoconf with meson ?
> > >
> > > There's no need to wait for the media summit to start answering those
> > > questions, if we can resolve the issue before meeting face to face,
> > > we'll have more time to discuss other questions :-)
> > >
> > > [1] https://lore.kernel.org/linux-media/20200408195611.55421-1-ariel@vanguardiasur.com.ar
> > > [2] https://lore.kernel.org/linux-media/20200429151639.5003-1-ariel@vanguardiasur.com.ar
> > > [3] https://lore.kernel.org/linux-media/20200618133303.28676-1-ariel@vanguardiasur.com.ar
> > > [4] https://lore.kernel.org/linux-media/20200721151434.115651-1-ariel@vanguardiasur.com.ar
> > > [5] https://lore.kernel.org/linux-media/20200806155519.79748-1-ariel@vanguardiasur.com.ar
> > > [6] https://lore.kernel.org/linux-media/20210317172227.620584-1-ariel.dalessandro@collabora.com
> > > [7] https://lore.kernel.org/linux-media/20210512184946.102863-1-ariel.dalessandro@collabora.com
> > > [8] https://lore.kernel.org/linux-media/20220829013327.5791-1-laurent.pinchart@ideasonboard.com