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:

quoted

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:

quoted

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

quoted

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