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

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

[Laurent Pinchart]

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 ?

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

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

Hi Laurent,

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.

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.

Regards,

	Hans

> 
> 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
> 

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

[Laurent Pinchart]

Hi Hans,

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.

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

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

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

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

On 08/09/2022 23:02, Laurent Pinchart wrote:
> 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 ?

Yes, please. I'd like to see a version with the FIXUPs squashed in, and
that makes it easy to revert if needed.

BTW, I think patch 1 can just be applied regardless, although v4l-utils.spec.in
needs updating as well (README -> README.md).

Regards,

	Hans

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

[Laurent Pinchart]

On Fri, Sep 09, 2022 at 11:03:56AM +0200, Hans Verkuil wrote:
> On 08/09/2022 23:02, Laurent Pinchart wrote:
> > 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 ?
> 
> Yes, please. I'd like to see a version with the FIXUPs squashed in, and
> that makes it easy to revert if needed.

https://lore.kernel.org/linux-media/20220909134412.21934-1-laurent.pinchart@ideasonboard.com

> BTW, I think patch 1 can just be applied regardless, although v4l-utils.spec.in
> needs updating as well (README -> README.md).

Done in v7.

-- 
Regards,

Laurent Pinchart