Re: [PATCH] t/meson.build: fix up tests for 'seen' branch

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 21, 2024, 06:04 UTC
Message-ID: <ZxXu2rG1ls8UcXug@pks.im>
In-Reply-To: <8b08b64a-aa5a-422d-9815-e67911a703e0@ramsayjones.plus.com>

On Sun, Oct 20, 2024 at 05:00:44PM +0100, Ramsay Jones wrote:

Thanks, I'll pick these up.

> Hmm, this is going to be a PITA as far as maintenance is concerned! :(
> If I am reading it correctly, the cmake solution uses file globbing
> to get the list of test files to run - could meson do the same?

In theory we can, yes. But there's a big problem with it, both in Meson and in CMake: the instructions to deduce source files only get executed at configure time. Consequently, when new files get added, the build instructions do not get updated accordingly and are thus broken. So CMake does get around this, but not in a way that is feasible for use as our main build system, and the same would be true for Meson.

For our integration-style tests I'd be okay with not listing the files individually, such that we instead use e.g. prove(1) to run all tests via a single test target. It would be a regression in functionality as we now cannot easily run e.g. "meson test t0000*", but at least we would not have to maintain the list of test scripts anymore.

But for our source files I don't really see an alternative to listing them out explicitly. You don't want things like git-rebase(1) or git-bisect(1) to be broken just because one of the commits happens to add or remove a file. And this is true for whichever build system we want to adopt as additional official buildsystem, whether that is CMake or Meson.

I guess we have less churn here anyway, and we would notice breakage more readily because things would stop compiling. So this is likely less of a problem compared to our tests.

Patrick