Em Sat, 20 Mar 2021 17:56:10 +0100 Gregor Jasny <gjasny@xxxxxxxxxxxxxx> 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; 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 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. 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. 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. Thanks, Mauro
