Re: [RFC PATCH v3 00/15] Modernize the build system
- From
Ramsay Jones <ramsay@ramsayjones.plus.com>
- Date
- Oct 24, 2024, 17:34 UTC
- Message-ID
- <787ef076-ba72-4a0d-bfd9-1f79de4f4039@ramsayjones.plus.com>
- In-Reply-To
- <Zxn1HWg7KxZwBy9h@pks.im>
On 24/10/2024 08:19, Patrick Steinhardt wrote:
> On Wed, Oct 23, 2024 at 03:38:18PM +0100, Ramsay Jones wrote: >>> Do any of the versions used maybe differ?
[snip]
Show 10 quoted lines
> Oh, wait! I can see that there's a "python3" 3.9.18 available as a > testing version. I don't quite understand how this works though, because > when I install it I still have Python 3.9.16. Seems like there are two > Python packages: "python3", which has the 3.9.18 test version, and then > there's "python39", which only has 3.9.16. The first one just seems to > be a meta package, so it doesn't contain anything. > > So... where did you get Python 3.9.18 from? You mentioned that it also > hogs all CPU, so could it be that this is basically a broken Python > installation?
Hmm I have no idea how my python installation got messed up (I never try to install TEST packages, but I do just install anything that is in the 'pending' page without even thinking!).
Last night I remembered that when installing something recently on windows it also (without even asking) installed a windows python as well, but that is hidden due to my path ...
$ /cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Python312/python --version Python 3.12.4 $
My current python packages (which include many obsolete python2 packages) looks like:
$ cygcheck -c python Cygwin Package Information Package Version Status python 3.0.0-1 OK $ cygcheck -c python3 Cygwin Package Information Package Version Status python3 3.9.18-1 OK $ which python python3 /usr/bin/python /usr/bin/python3 $ python --version Python 3.9.18 $ python3 --version Python 3.9.18 $
Go away and wrangle with setup.exe ...
$ python --version
Python 3.9.16
$ python3 --version
Python 3.9.16
$ which python python3
/usr/bin/python
/usr/bin/python3
$ cd git
$ mkdir build
$ cd build
$ meson setup .. -Dprefix=$HOME
...
git v2.47.GIT
User defined options
prefix: /home/ramsay
Found ninja-1.12.0 at /usr/bin/ninja
$ ninja
[699/699] Linking target t/helper/test-tool.exe
$ meson test 't000*'
ninja: Entering directory `/home/ramsay/git/build'
ninja: no work to do.
1/9 t0002-gitfile OK 10.52s
2/9 t0004-unwritable OK 6.78s
3/9 t0005-signals OK 5.96s
4/9 t0003-attributes OK 54.40s
5/9 t0006-date OK 31.39s
6/9 t0001-init OK 61.68s
7/9 t0007-git-var OK 12.93s
8/9 t0008-ignores FAIL 106.29s exit status 1
>>> PATH='/home/ramsay/git:/usr/bin:/usr/bin:/usr/bin:/usr/bin:/home/ramsay/bin:/usr/bin:/usr/bin:/home/ramsay/bin:/home/ramsay/bin:/usr/local/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Python312/Scripts:/cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Python312:/cygdrive/c/Users/ramsay/AppData/Local/Programs/Python/Launcher:/cygdrive/c/Users/ramsay/AppData/Local/Microsoft/WindowsApps:/usr/lib/lapack' MALLOC_PERTURB_=105 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 GIT_BUILD_DIR=/home/ramsay/git/build /usr/bin/sh t0008-ignores.sh
9/9 t0000-basic OK 193.52s
Ok: 8
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /home/ramsay/git/build/meson-logs/testlog.txt
$
So, a big improvement! :)Having a quick squint at the failure, it '# failed 1 among 397 test(s)' which was 'not ok 391 - correct handling of backslashes', which is the only test marked with a '!CYGWIN' prerequisite! ;) So it seems that I am doing something wrong, which results in the prerequisite not being set.
I haven't debugged that yet, but I wanted to note the above improvement having 'fixed' my python installation. (It doesn't look good for the TEST package! :) ).
Thanks!
ATB, Ramsay Jones `