On 20/02/2023 22:59, Laurent Pinchart wrote:
Hi Tomi,
On Mon, Feb 20, 2023 at 01:13:09PM +0200, Tomi Valkeinen wrote:
On 12/02/2023 02:51, Laurent Pinchart wrote:
Hello everybody,
This series is the latest (and greatest) attempt to switch v4l-utils
from autotools to meson.
Compared to v7, the series has been rebased on top of the latest master
branch, and lots of fixes have been added. All review comments should
have been addressed. Detailed changelogs are included in individual
patches, in particular in patch 3/6.
The rebase was a bit painful due to the new v4l2-tracer tool and its
code generation script. While meson handles code generation fine, it
required fixes to the script to be able to specify the output directory
and to generate the trace and retrace sources separately. Many thanks to
Sakari for his help with this, which I've included in this series as
patch 1/6.
Gregor, I haven't included the Tested-by tag you gave on v7 as v8
contains many small changes. Sorry about that.
The patches are based on 3 pending patches for v4l-utils that have been
posted to the list in the last couple of days:
- libv4lconvert: Don't ignore return value of ftruncate()
- keytable: Add -fno-stack-protector compilation option
- configure.ac: Add option to disable compilation of v4l2-tracer
None are strictly required, but I've included the equivalent of the
second and third patches in the meson support, so I wanted to base the
patches on top of the autotools' equivalent. I expect those three
patches to be merged soon.
As far as I can tell, meson support is now ready. I can address review
comments in a v9 if there are any, but I'd like to merge it soon to
avoid another painful rebase. I'll be available to fix issues on top if
any problem is encountered later.
A tag that includes this series can be found at
git://linuxtv.org/pinchartl/v4l-utils.git tags/meson-v8
If I build this for x86 or arm64 with default options, it builds fine. If I build for arm32 (against my buildroot rootfs), the build fails:
[197/254] Compiling C object contrib/test/v4l2gl.p/v4l2gl.c.o
FAILED: contrib/test/v4l2gl.p/v4l2gl.c.o
ccache /home/tomba/work/buildroot/output32/host/bin/arm-buildroot-linux-gnueabihf-gcc -Icontrib/test/v4l2gl.p -Icontrib/test -I../contrib/test -I../lib/include -I../include -I/home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include -I/home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/libdrm -I/home/tomba/work/buildroot/output32/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/valgrind -I. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O2 -g -Wpointer-arith -D_GNU_SOURCE -DPROMOTED_MODE_T=int -DENABLE_NLS -MD -MQ contrib/test/v4l2gl.p/v4l2gl.c.o -MF contrib/test/v4l2gl.p/v4l2gl.c.o.d -o contrib/test/v4l2gl.p/v4l2gl.c.o -c ../contrib/test/v4l2gl.c
../contrib/test/v4l2gl.c:268:60: error: expected ‘,’ or ‘;’ before ‘V4L_UTILS_VERSION’
268 | const char *argp_program_version = "V4L2 grabber version " V4L_UTILS_VERSION;
| ^~~~~~~~~~~~~~~~~
Thank you for the report. I've test-compiled for arm32, but my build
environment may not have the features needed by v4l2gl.c, so it may have
been skipped. Would you be able to check what goes wrong ? v4l2gl.c
includes config.h, so V4L_UTILS_VERSION should be defined. Does your
config.h (generated in the build directory) define V4L_UTILS_VERSION ?
Does your buildroot environment provide a config.h that is being picked
instead ?
Yes, valgrind's directory has config.h (not sure why valgrind headers
are needed for v4l2gl). I think the problem is that the build dir (-I.)
is very late in the command line, in fact it seems to be the last
include dir listed.
Isn't config.h and the like more commonly included via "-include"?
Tomi
