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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 21, 2024 at 08:04:16AM +0200, Patrick Steinhardt wrote:
> On Sun, Oct 20, 2024 at 05:00:44PM +0100, Ramsay Jones wrote:
>
> Thanks, I'll pick these up.

Thanks. Please make sure to let me know which topic(s) that the new
version of ps/build depends on as a result so I can queue it properly.

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

I quite like the ability to run tNNNN-*.sh individually when spelled
like that (i.e. including the test number, but not the full script
name).

I find that for the areas that I have worked on most over the years that
I have the relevant test numbers committed by heart, but often don't
know the full script name. So it is nice to be able to refer to them by
number only.

Am I reading it write that this suggests that Meson would lose that
ability?

Thanks,
Taylor




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux