[06:38] *** ChanServ sets mode: +v hverkuil
[07:16] *** ChanServ sets mode: +v hverkuil
[11:50] <mchehab> hi all
[11:52] <syoung> hi all
[11:52] <mchehab> hi all
[11:53] <syoung> mchehab: did you see https://www.spinics.net/lists/linux-media/msg174472.html
[11:53] <syoung> I think there are a few outstanding patches for dtv-scan-tables
[11:53] <mchehab> no, I didn't
[11:54] <mchehab> I usually handle things that are pending for some time there
[11:54] <mchehab> there is someone actually responsible for the rpo
[11:54] <syoung> who is that?
[11:54] <mchehab> Oliver Schinagl
[11:55] <mchehab> I guess I can grant you commit permissions there too
[11:56] <mchehab> done
[11:56] <syoung>  Olliver Schinagl has not committed in 1.5 years
[11:56] <syoung> mchehab: thanks! Anything I should be aware of?
[11:56] <mchehab> not really
[11:56] <syoung> ok, just checking.
[11:57] <syoung> the other thing I wanted to ask was about the v4l-utils meson build system: https://patchwork.linuxtv.org/project/linux-media/patch/20200806155519.79748-3-ariel@vanguardiasur.com.ar/
[11:59] <syoung> hverkuil: ping
[11:59] <mchehab> I know about nothing about meson
[12:00] <mchehab> except that it breaks from time to time at the automatic CI builds
[12:00] <mchehab> at linuxtv jenkins instance
[12:01] <mchehab> so far, it sounded to me as a lot less reliable than autotools
[12:01] <mchehab> but never tested the v4l-utils port
[12:02] <pinchartl> mchehab: FUD :-)
[12:02] <pinchartl> what breaks in the CI builds ?
[12:02] <pinchartl> are you referring to libcamera ?
[12:02] <mchehab> yes
[12:02] <mchehab> that's my only experience with Meson :-)
[12:03] <mchehab> (plus a few things I had to build myself, but not needing of do anything to make it work)
[12:03] <mchehab> but it is really very rare for me to have to use Meson
[12:03] <pinchartl> some issues were caused by bugs in libcamera, can hardly blame meson for that, I'm sure I could write equally buggy autoconf code :-)
[12:03] <mchehab> yes, but there were also bugs due to the toolchain itself
[12:03] <mchehab> it sounds to me that it is less stable than autotools
[12:04] <mchehab> I can't remember the last time I found a bug at the toolchain itself
[12:04] <pinchartl> among those, one was an incorrect use of meson in the build scripts (not blaming you for that, we were figuring out how to use it in CI, so mistakes are normal in the beginning)
[12:04] <pinchartl> there was one caused by meson itself, due to something weird that libcamera does
[12:04] <pinchartl> (I've submitted a fix to meson for that, and it has been merged)
[12:05] <syoung> I can't say I ever particularly liked autoconf. It's far too complicated for a build system. meson seem much more elegant.
[12:05] <mchehab> yeah, I remember
[12:05] <pinchartl> I wouldn't say it's less stable in general, it also depends what you do with it. there are interesting compared to autotools, and new features sometimes have bugs
[12:05] <mchehab> syoung: I guess the point is: what would be the real benefit of switching
[12:06] <pinchartl> autotools is more stable because it's not really developed anymore ;-)
[12:06] <mchehab> yep. That's perfect!
[12:06] <mchehab> it is reliable
[12:06] <pinchartl> the maintenance effort will be lower, meson is simple to use, and build time will be reduced
[12:06] <pinchartl> meson + ninja is faster than autotools + make
[12:06] <syoung> much faster
[12:07] <syoung> and +1 on the maintenance effort
[12:07] <mchehab> so what? building v4l-utils is a lot faster than building the Kernel
[12:07] <pinchartl> I've also found that there's less magic involved with meson compared to autotools. it's easier to understand what's happening
[12:07] <pinchartl> of course it requires getting familiar with meson, there's some ramp-up time
[12:07] <mchehab> building time was never an issue at v4l-utils
[12:07] <pinchartl> but it's worth it
[12:08] <syoung> how about committing the meson build system and then seeing if we like it?
[12:08] <mchehab> pinchartl: sort time, it requires a lot more maintainance time, due to the learning curve
[12:08] <syoung> it certainly has my vote.
[12:09] <mchehab> gah
[12:09] <mchehab> sort->short
[12:09] <syoung> well, I never learned autotools because of my dislike of it. I'm more motivated to learn meson so it will be less effort
[12:10] <pinchartl> it requires learning meson, yes. I'd say that's a plus, it will improve your skillset :-) lots of projects are moving away from autotools+make, it's good to be prepared and not be stuck in the past
[12:10] <mchehab> being based on python, Meson will never be stable...
[12:10] <mchehab> as python itself is a mess
[12:11] <syoung> it's perfectly possible to write stable code in python
[12:11] <mchehab> even minor version changes break things... python 3.8 recently broke something (zbar, I guess)
[12:11] <mchehab> syoung: never found anything stable on python side
[12:11] <mchehab> language version changes always break things
[12:12] <mchehab> it is not like m4 or c
[12:12] <pinchartl> can you tell me with a straight face that a gcc upgrade has never broken a kernel ? :-)
[12:12] <mchehab> yeah, implementing things on m4 is not very nice, but once done, you can rely that this will work forever
[12:12] <syoung> m4 is a terrible choice for a build system
[12:13] <mchehab> python is a terrible choise. period.
[12:13] <mchehab> :-D
[12:13] * mchehab runs
[12:13] <mchehab> choise->choice
[12:13] <pinchartl> I won't force you to use meson, you can stick to tools of the past if you want, but we all want to move forward, it would be a shame to leave you behind ;-)
[12:14] <sailus> Hello!
[12:14] <sailus> (My reminder is still in winter time. Oops.)
[12:15] <pinchartl> sailus: understandable, we have only recently switched to summer time :-)
[12:15] <syoung> meson has better integration with IDEs like vscode
[12:16] <pinchartl> syoung: not sure that's an argument for v4l-utils, but it's certainly nice to have options
[12:17] <mchehab> syoung: I can try to take a look at the pending patchset when I have some time
[12:18] <mchehab> and see if it would provide at least the same features that we have right now with our current building system
[12:18] <sailus> I wonder it it'd help to rewrite Meson in Perl.
[12:18] <pinchartl> :-D
[12:19] <syoung> or re-write meson on rust
[12:19] <syoung> in rust
[12:19] <pinchartl> there's an idea to port meson to go, for android. it's crazy though (and wouldn't switch it from python to go, it would be a parallel implementation)
[12:19] <mchehab> sailus: using a more stable language would be a good thing for Meson, IMHO :-)
[12:20] <mchehab> I mean, the end goal of the building system is that people should not have any troulbes with the toolchain...
[12:20] <mchehab> as it is up to the building system to detect what's required and to complain about missing things/broken things on a given machine
[12:20] <sailus> Well, I don't really use Python but I haven't seen practical issues in programs written in Python, at least related to language definition stability (for it really appears not to be that stable).
[12:20] <pinchartl> should we ask Gregor's opinion ? isn't he the maintainer of v4l-utils ?
[12:21] <mchehab> it the toolchain itself depends on an specific verson of the language it uses (with is the case of all Python things), then it sorts of defeats its purpose
[12:21] <syoung> Gregor has already given it his blessing. It does everything he needs it to do.
[12:21] <sailus> In relative terms, Python is almost as old as Perl nowadays as a language.
[12:21] <syoung> See the email thread.
[12:22] <syoung> mchehab: there are quite a few in favour, please read the email thread.
[12:22] <pinchartl> mchehab: I constantly have to hack the autotools files in v4l-utils when I cross-compile v4l-utils for platforms that have missing dependencies. there may be a way to specify things in command line arguments to configure, but for some of the dependencies I never figured out how, even though it's supposed to work
[12:22] <pinchartl> I'd argue that autotools is painful today
[12:22] <pinchartl> syoung: ok, I had missed that. good to know
[12:22] <sailus> I wonder how difficult it'd be to come up with Meson build files that would work in all the cases where autoconf currently does.
[12:23] <sailus> I have to admit I don't know Meson either, but I do know some autoconf.
[12:23] <sailus> pinchartl: How has Meson worked for you in libcamera?
[12:24] <pinchartl> sailus: really well I have to say
[12:24] <pinchartl> there was definitely some ramp up time
[12:24] <mchehab> I guess libcamera has less options than v4l-utils
[12:24] <pinchartl> we've had issues due to mishandled dependencies, cause by us not specifying the depedencies in the first place
[12:25] <mchehab> one of the things I miss with meson (but it is probably because I never tried to understand it) is the lack of something like:
[12:25] <pinchartl> can hardly blame meson for that :-) it's true that developers need to learn how to use it though, but it's not difficult
[12:25] <mchehab> ./configure --help
[12:25] <pinchartl> we've had a few issues with meson itself
[12:25] <pinchartl> meson uses out of tree builds
[12:25] <pinchartl> (like the kernel with O=..., but by default)
[12:26] <mchehab> that's something that sucks on meson
[12:26] <mchehab> I really hate OOT build
[12:26] <sailus> mchehab: It's not only options. There are features such as all-static linking that aren't as such visible in the options but for which the autoconf files were still written for.
[12:27] <mchehab> sailus: yeah. The autoconf provides a lot of flexibility...
[12:27] <mchehab> supporting both OOT and in-tree builds, static and dynamic links, etc
[12:27] <mchehab> plus it is highly customisable via m4 macros
[12:28] <mchehab> (and there's a vast amount of ready to use m4 macros for it)
[12:28] <pinchartl> but they were due to weird things we were doing, that nobody had done before
[12:28] <mchehab> pinchartl: in-tree building is what I do daily basis
[12:28] <pinchartl> we've also had issues with missing features, which turned out to then be available by just upgrading meson :-)
[12:28] <pinchartl> mchehab: what's the upside of in-tree builds ?
[12:29] <mchehab> I would ask the reverse: what's the upside of OOT? It is very messy...
[12:29] <mchehab> to need to create a special dir just to build things
[12:29] <mchehab> IMHO
[12:29] <pinchartl> there are many upsides
[12:30] <pinchartl> one of them is that you can have multiple build directories
[12:30] <mchehab> for me, there are many upsides of in-tree building
[12:30] <pinchartl> for CI, when you want to compile the same sources for different archs, it's very handy
[12:30] <mchehab> one of the things I don't like on debian is the need of doing OOT builds
[12:30] <pinchartl> it also makes it easy to wipe the build directory, there's no leftover in the source tree
[12:31] <pinchartl> it also enables compiling sources that are read-only, which is nice for CI too, but also ensures that the build is doing the right thing are not modifying sources in an unexpected way
[12:31] <pinchartl> you can of course still generate sources (or headers)
[12:32] <mchehab> one of the problems with several OOT toolchain builds is that one need to remove the build directory as otherwise the build won't do things right
[12:32] <pinchartl> why ?
[12:32] <mchehab> I remember I had to manually do that several times on libcamera
[12:32] <pinchartl> OOT builds are still incremental
[12:32] <mchehab> because otherwise some dependencies are not properly handled
[12:32] <pinchartl> yes, and that was caused by incorrect usage of meson in the beginning
[12:33] <pinchartl> and OOT builds make that process easier, if you want to ensure that a fresh (non-incremental) build works fine, you just create a new build directory
[12:33] <pinchartl> I see absolutely no drawback
[12:34] <pinchartl> same for the kernel, I only use out-of-tree builds
[12:34] <mchehab> you can do OOT with autotools
[12:34] <mchehab> I only use in-tree builds
[12:34] <pinchartl> you shouldn't :-)
[12:34] <mchehab> even cmake offers such flexibility
[12:35] <mchehab> (btw, the learning curve for cmake is not high)
[12:35] <pinchartl> does cmake support in-tree builds ? I thought it was OOT only
[12:35] <mchehab> yes, it does
[12:35] <mchehab> cmake .
[12:35] <mchehab> make
[12:35] <pinchartl> I've only used it OOT, never looked for anything else :-)
[12:35] <pinchartl> if you think learning cmake isn't an issue, then you'll be fine with meson
[12:35] <pinchartl> I've used both, meson is simpler
[12:36] <mchehab> how can I do an in-tree building with meson?
[12:36] <pinchartl> you can't, because you shouldn't
[12:36] <mchehab> tha's for sure my first question :-O)
[12:36] <pinchartl> what's the point of doing an in-tree build ?
[12:37] <mchehab> it is a lot easy to see binaries and c files at the same place, and it is a lot easier when scripts need to be called
[12:38] <pinchartl> how do you mean easier when scripts have to be called ?
[12:38] <mchehab> I mean: Makefile dependencies are more direct
[12:38] <pinchartl> I'm not sure to understand
[12:39] <mchehab> the .o file is placed at the same dir as the .c
[12:39] <pinchartl> with autotools it's more complicated to make OOT work, you have to write your Makefile rules with OOT in mind
[12:39] <mchehab> that's the standard way Makefiles work
[12:39] <pinchartl> with meson you don't have to care, it's transparent
[12:39] <mchehab> placing it elsewere is weird - at least for me :-D
[12:40] <mchehab> "don't have to care" is something that afraids me a lot
[12:41] <mchehab> I do care about the building process
[12:41] <pinchartl> I mean you don't have to manually handle it
[12:41] <mchehab> doing things behind my back is something I don't like
[12:41] <sailus> pinchartl: Which Meson version does the libcamera currently need?
[12:42] <pinchartl> >= 0.47
[12:42] <sailus> It seems Meson is still developing fast, and Debian Buster, for instance, has 0.49.2.
[12:42] <pinchartl> we may upgrade later, there are neat features in some newer versions
[12:42] <sailus> Ok.
[12:42] <sailus> I think it'd be annoying if you'd have to upgrade Meson just to compile v4l-utils.
[12:43] <pinchartl> we've looked at what major distros ship when deciding which meson version to require
[12:43] <sailus> pinchartl: I was thinking the same.
[12:43] <pinchartl> libcamera requires a kernel >= 5.0
[12:43] <sailus> So all should be good if the latest stable versions of major distros ship a version of Meson that works.
[12:44] <mchehab> anything else for today's meeting? I need to do some other things in a few
[12:44] <sailus> Not on my side.
[12:44] <mchehab> is in-tree building feature planned for Meson?
[12:45] <pinchartl> not that I know of
[12:46] <pinchartl> I think they specifically want not to have in-tree builds
[12:46] <syoung> why would you want in-tree building? mixing source code and binary seems like a terrible idea
[12:46] <mchehab> not mixing seems a terrible idea to me
[12:47] <mchehab> it means twice the efforts if I want to check where an object file is
[12:48] <mchehab> as I'll need first to check where the source is, and then search for its object(s) at the destination dir
[12:50] <mchehab> anyway, I need to go
[12:50] <mchehab> ttyl
[12:55] <hverkuil> Oops, completely forgot the meeting.
[12:58] <pinchartl> hverkuil: is it winter for you too ? :-)
[12:58] <hverkuil> No, I was working on a fun project and I lost track of time :-)
[12:59] <pinchartl> we've had "fun" discussing meson ;-)
[13:00] <hverkuil> I'm not convinced about meson. I would need to look at the latest version to check if everything that I need is working. Gregor's input is certainly also needed.
[13:01] <syoung> hverkuil: have a look at the email thread. Gregor has some input
[13:01] <hverkuil> Once thing that I really want to avoid is that we end up with two build systems. A transition period of 2-3 months is fine, but after that we need to kill one of the two.
[13:03] <pinchartl> hverkuil: fully agreed
[13:03] <pinchartl> maintaining them in parallel for the long term would be a burden
[13:03] <pinchartl> so we should switch or not switch, but not do both
[13:09] <sailus> I think we could have the other in a separate branch, and with enough testing, merge it.
[13:39] <syoung> if we have it on another branch, it will just be ignored. I think it's better to have it merged to master first, and then later either remove autotools or meson build system based on what we decide
[15:00] <sailus> syoung: I think development could be done in a separate branch.
[15:00] <sailus> I wouldn't expect everything to work right from the beginning.
[15:00] <sailus> Just an idea.
[15:01] <pinchartl> sailus: unless I'm mistaken, the latest version of the conversion series is supposed to work right :-)
[16:18] <sailus> pinchartl: That's not clear from the patchset. The installation documentation is left as-is.
[16:19] <pinchartl> sailus: could you mention that in a reply to the patches ?
[16:20] <sailus> Absolutely.