Re: [v4l-utils v4 2/5] Add support for meson building

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Mauro,

On Sat, Mar 20, 2021 at 08:32:09PM +0100, Mauro Carvalho Chehab wrote:
> Em Sat, 20 Mar 2021 17:56:10 +0100 Gregor Jasny escreveu:
> 
> > Hello,
> > 
> > Thank you again for these patches. Building v4l-utils has never been so 
> > fast and easy. It will accelerate my Debian / Ubuntu packaging and 
> > really sparks joy!
> > 
> > On 17.03.21 18:22, Ariel D'Alessandro wrote:
> > > Supports building libraries and tools found in contrib/, lib/ and
> > > utils/ directories, along with the implemented gettext translations.  
> > 
> > Here's a patch on top of your tree:
> > https://gitlab.com/gjasny/v4l-utils/-/commit/a9853f79c2675bf08fc3e93f15aa4158c9769bdd
> > 
> > I changed the following:
> > * Use pkgconfig to detect libbpf (like configure.ac does)
> > * check for libbpf presence in the keytable subdir (like it's done for 
> > libelf
> > * refined the empty rc_keymaps dir hack with something supported by 
> > meson: https://github.com/mesonbuild/meson/issues/2904 (your hack 
> > stopped working for me with meson on Ubuntu 20.04.2)
> > 
> > With those changes I could successfully build a Debian package using meson.
> > 
> > Thanks,
> > Gregor
> > 
> > PS: I could not find Mauro in the CC list.
> 
> I'm not a lover of autoconf tools. Yet, replacing from it on this
> project sounds a bad idea, for a couple of reasons.
> 
> The main one is that nobody has yet provided any real reason about
> *why* auto-tools should be replaced.
> 
> Auto-tools is reliable, stable and has been used since the
> beginning of this project. It is well-known and it is maintained
> upstream. It is present on all Linux distros and installing it
> doesn't require lots of packages for it to work. It is easy to
> keep maintaining it, and I never had to touch the Jenkins builder
> due to some troubles with autoconf packages.
> 
> The only package we have at jenkins using meson broke quite a
> few times due to problems with meson toolset versions.
> 
> So, switching from autotools will just place us on an unknown
> territory for no reason.
> 
> Besides that:
> 
> 1) meson doesn't support yet in-tree compilation. This is
>    a feature that I use a lot;

I'm curious, what does in-tree compilation allow that out-of-tree
compilation doesn't ?

> 2) Meson setup is *a way more complex* than autotools. With
>    auto-tools, everything is on a single file (plus standard
>    Makefiles):
> 	
> 	$ wc -l configure.ac
> 	660
> 
>   The meson config is a way bigger and it is spread on multiple
>   files, with is 3 times bigger than our current configure.ac:
> 
>   $ wc -l $(find . -name 'meson*' -type f|grep -v .git)
>     3 ./v4l-utils-po/meson.build
>     3 ./libdvbv5-po/meson.build
>   117 ./lib/libv4lconvert/meson.build
>    23 ./lib/libv4l-mplane/meson.build
>    70 ./lib/libv4l2/meson.build
>    36 ./lib/libv4l2rds/meson.build
>    61 ./lib/libv4l1/meson.build
>   158 ./lib/libdvbv5/meson.build
>    11 ./lib/meson.build
>   151 ./utils/keytable/rc_keymaps/meson.build
>    31 ./utils/keytable/bpf_protocols/meson.build
>    81 ./utils/keytable/meson.build
>    70 ./utils/dvb/meson.build
>    14 ./utils/libmedia_dev/meson.build
>     8 ./utils/cx18-ctl/meson.build
>    58 ./utils/v4l2-compliance/meson.build
>    19 ./utils/cec-follower/meson.build
>    80 ./utils/qv4l2/meson.build
>    82 ./utils/qvidcap/meson.build
>    23 ./utils/ir-ctl/meson.build
>    22 ./utils/cec-compliance/meson.build
>    16 ./utils/libv4l2util/meson.build
>    13 ./utils/rds-ctl/meson.build
>    43 ./utils/media-ctl/meson.build
>    45 ./utils/libcecutil/meson.build
>    18 ./utils/cec-ctl/meson.build
>    16 ./utils/v4l2-dbg/meson.build
>    75 ./utils/v4l2-ctl/meson.build
>    14 ./utils/v4l2-sysfs-path/meson.build
>    13 ./utils/ivtv-ctl/meson.build
>    46 ./utils/meson.build
>    50 ./meson_options.txt
>    34 ./doc/meson.build
>     8 ./contrib/cobalt-ctl/meson.build
>    11 ./contrib/xc3028-firmware/meson.build
>    44 ./contrib/gconv/meson.build
>     7 ./contrib/rds-saa6588/meson.build
>    14 ./contrib/decode_tm6000/meson.build
>   143 ./contrib/test/meson.build
>    13 ./contrib/meson.build
>   318 ./meson.build
>  2062 total

That's not a fair comparison, meson.build replaces configure.ac and
Makefile.am, as well as m4/*. There's also bootstrap.sh and most
probably other ancillary files.

$ cat $(find . -name 'Makefile.am' -type f | grep -v .git) configure.ac m4/* | wc -l
2549

>   Ok, part of it seems because meson doesn't like Makefiles, which
>   is, IMHO, a misfeature, as it makes harder to identify what are
>   the actual build instructions for each target.
> 
> 4) As the new build config files are bigger and use a different
>    syntax than configure.ac, it will require time and efforts to
>    learn how to use and modify it. Again, there's no need for
>    doing that;
> 
> 5) I don't know how to integrate meson with Coverity, as the
>    current procedure assumes an in-tree Makefile set that
>    will be used by cov-build to produce an out-of-tree build.

We run coverity on libcamera and haven't had any meson-related issues.
I'm sure we can help if you need assistance.

> 6) with our configure.ac, it is easy to check what options
>    were enabled or not:
> 
>   compile time options summary
>   ============================
> 
>     Host OS                    : linux-gnu
>     X11                        : yes
>     GL                         : yes
>     glu                        : yes
>     libelf		       : yes
>     libjpeg                    : yes
>     libudev                    : yes
>     pthread                    : yes
>     QT version                 : v5.4 with QtGL
>     ALSA support               : yes
>     SDL support		       : yes
> 
>     build dynamic libs         : yes
>     build static libs          : yes
> 
>     gconv                      : no
> 
>     dynamic libv4l             : yes
>     v4l_plugins                : yes
>     v4l_wrappers               : yes
>     libdvbv5                   : yes
>     dvbv5-daemon               : yes
>     v4lutils                   : yes
>     qv4l2                      : yes
>     qvidcap                    : yes
>     v4l2-ctl uses libv4l       : yes
>     v4l2-ctl-32                : no
>     v4l2-compliance            : yes
>     v4l2-compliance uses libv4l: yes
>     v4l2-compliance-32         : no
>     BPF IR Decoders:           : no
> 
>   at least the current meson patches don't have anything similar.

Meson has a summary() function that offers the same feature. If it's not
used in the current patches, it can easily be added.

>   This also affects Coverity builds, as we need the selected options
>   to be logged, as the coverity scan complains if the code is only
>   partially built (to the point to simply ignore incomplete builds):
> 
> 	Subject: Coverity Scan: Analysis failed for v4l-utils
> 
> 	Your request for analysis of v4l-utils  is failed.
> 	    Analysis status: Failure
> 	    Please fix the error and upload the build again.
> 	
> 	    Error details:
> 	    The build uploaded has been only partially compiled. We recommend at least 85% capture success to avoid false-positives during analysis. As per last few lines of cov-int/build-log.txt, the percentage of compilation units ready for analysis is 80% which is less than the expected 85%
> 
> 7) As meson relies on Python, which has unstable APIs, which breaks
>    from time to time, it seems a lot less reliable than
>    configure.ac, which relies on a lot more stable language (m4).
> 
> 
> >	diff --git a/README.md b/README.md
> >	index a2322c6e3af3..a4ff7511390b 100644
> >	--- a/README.md
> >	+++ b/README.md
> >	@@ -18,6 +18,10 @@ There is also a wiki page for the v4l-utils:
> >	 
> >	 ## Building
> >	 
> >	+Temporarily, both meson and autotools build systems are supported in parallel.
> >	+*NOTE*: Packagers should be aware that autotools support will be dropped soon,
> >	+to be fully replaced by meson.
> >	+
> 
> NAK to drop autotools. Even if we would add support for some new
> building system that would support in-tree build (cmake would be 
> a better option, IMHO), autotools should remain the main building
> system for at least a couple of years, in order for us to be sure
> that it would work properly and that people will start dominating
> the new way.

I'm curious again, would you rather drop autotools, or contributors to
v4l-utils ?

-- 
Regards,

Laurent Pinchart