On Mon, Oct 21, 2024 at 11:56:42PM +0100, Ramsay Jones wrote:
> On 20/10/2024 09:51, Eli Schwartz wrote:
> > On 10/18/24 12:08 PM, Ramsay Jones wrote:
> [snip]
> > possibly because due to ninja's juggling of pseudo ttys, the python
> > runtime for "meson test" thinks it is *not* running in a tty. I know
> > that ninja messes around with this in counterintuitive ways in general,
> > but I am not sure exactly how that interacts with the console pool. But
> > regardless of the reason -- if it is happening at the python level, then
> > exporting PYTHONUNBUFFERED=1 may help. It's something I've had to do
> > before for programs other than meson, at least.
>
> Unfortunately, the 'PYTHONUNBUFFERED=1' idea didn't work. In fact nothing
> I have tried on cygwin has worked. For example, if I use meson to run just
> few tests, like so on Linux:
>
> $ meson test --no-rebuild --print-errorlogs 't000*'
> 1/9 t0000-basic OK 7.52s
> 2/9 t0001-init OK 1.88s
> 3/9 t0002-gitfile OK 0.37s
> 4/9 t0003-attributes OK 1.35s
> 5/9 t0004-unwritable OK 0.23s
> 6/9 t0005-signals OK 0.16s
> 7/9 t0006-date OK 0.73s
> 8/9 t0007-git-var OK 0.40s
> 9/9 t0008-ignores OK 3.09s
>
> Ok: 9
> Expected Fail: 0
> Fail: 0
> Unexpected Pass: 0
> Skipped: 0
> Timeout: 0
>
> Full log written to /home/ramsay/git/build/meson-logs/testlog.txt
> $
>
> On cygwin it looks like:
>
> $ meson test --no-rebuild --print-errorlogs 't000*'
> 1/9 t0002-gitfile OK 12.32s
> [2-4/9] 🌖 t0003-attributes 12s
>
> Which actually looks nothing like what actually happens! The first line
> is actually the result of (*maybe*) running all 9 tests, but during that
> time the line started with '[1-4/9] ...' and they didn't run in sequence
> but jumped around ending with t0002. Then on the second line, it almost
> immediately hung, again with python hovering up all the cpu cycles. So
> I had to kill the task from a second terminal.
>
> Actually, I tell a lie, I did get a single test to work on cygwin:
>
> $ meson test --no-rebuild --print-errorlogs 't0001*'
> 1/1 t0001-init OK 32.95s
>
> Ok: 1
> Expected Fail: 0
> Fail: 0
> Unexpected Pass: 0
> Skipped: 0
> Timeout: 0
>
> Full log written to /home/ramsay/git/build/meson-logs/testlog.txt
> $
>
> Notice that this took much longer, at 32.95s, than (what looked like) all
> nine tests above at 12.32s. (although via 'make test' t0000-basic.sh alone
> took 124.13s for v2.47.0!).
>
> Patrick, how do you run the tests on cygwin?
I didn't have to do anything special here, so this is quite puzzling. In
a fully-updated Cygwin installation:
$ which meson
/usr/bin/meson
$ meson --version
1.3.2
$ python --version
3.9.16
$ mkdir build
$ meson setup ..
... autoconfiguration logs ...
$ meson test 't000*'
ninja: Entering directory `/home/Patrick Steinhardt/git/build'
[582/582] Linking target git-receive-pack.exe
1/9 t0005-signals OK 4.17s
2/9 t0004-unwritable OK 4.58s
3/9 t0002-gitfile OK 6.95s
4/9 t0007-git-var OK 8.15s
5/9 t0006-date OK 15.42s
6/9 t0003-attributes OK 26.84s
7/9 t0001-init OK 29.09s
8/9 t0008-ignores OK 57.17s
9/9 t0000-basic OK 83.82s
Ok: 9
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /home/Patrick Steinhardt/git/build/meson-logs/testlog.txt
This is starting with a fresh repo, I executed `git clean -dfx`
beforehand.
Do any of the versions used maybe differ?
Patrick
