Hi Eric & Ævar, On Mon, 30 Nov 2020, Eric Sunshine wrote: > On Mon, Nov 30, 2020 at 4:20 AM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: > > > I did wonder "why not just call perl -e 'print $<' ?" first. But then > > found (by reading the Perl source[1], didn't actually test this) that it > > fakes up UID=0 for everything on Windows. > > I totally forgot about Perl's `$<`. > > Under the Git for Windows SDK, Perl's `$<` returns a large positive > number. I suspect this differs from what you saw in the Perl source > code because the Windows-specific code you looked at does not come > into play in this case. For Git for Windows SDK, Perl is almost > certainly instead built in Unix-like mode, linking against the MSYS2 > library for its POSIX-like emulation, thus the Windows-specific Perl > goop is not needed. Correct. > > I couldn't find any "is root?" in our tree that relies on Perl's $< in a > > bad way (the couuple of occurances seem innocuous), we have some "id -u" > > checks, but those also seem OK if it returned 0 on Windows (what does it > > return?). Seems the worst we'd do there is unintentionally skip some > > "skip this as root" tests. > > Under Git for Windows SDK, `id -u` returns the same large positive > number as returned by Perl's `$<`, which makes sense since `id` is > also likely linked against the MSYS2 library. Correct. > > I know Johannes (CC'd) has (this is from wetware memory) wanted to > > (understandably) not need to bother with Perl as part of GFW, but I > > can't remember if that's for a reason covered by NO_PERL=YesPlease, > > i.e. packaging it up, or whether it's also to not wanting to provide a > > perl for the test suite. > > I _think_ that was for the NO_PERL=YesPlease case, but I expect Dscho > can answer more concretely. I assume you're referring to NO_PERL being set in the CI builds on Windows? There were two problems we tried to address via setting NO_PERL: MSYS2 problems on 32-bit Windows (where the `fork()` emulation would frequently run into DLL base address issues due to the limited address space combined with the requirement to keep the MSYS2 DLL at a _fixed_ memory location), and speed. We no longer run the 32-bit Pipeline, saving a couple electrons. But speed is still a major concern with the automated test suite. Just have a look: https://github.com/git/git/actions/runs/393089617 shows the `linux-clang` job running for a little over 27 minutes, and that includes the build and two test suite runs (taking 12m08s and 12m41s, respectively). At the same time, the Windows tests (_not_ including the build), split into 10 parallel jobs, take between ~8-13.5 minutes to run (granted, there is a 1.5 minute overhead in each split job to download and set up stuff). And that's _skipping_ the test cases requiring Perl, or GPG, or Perforce, etc... Perl is slow. Even on Linux. Running t3701 with the scripted vs the built-in `git add -i` shows a stark contrast. See for yourself: https://github.com/git/git/runs/1478012705?check_suite_focus=true#step:4:994 says that the scripted version took just under 25 seconds, while https://github.com/git/git/runs/1478012705?check_suite_focus=true#step:4:1908 says that the built-in version took just over 8 seconds (this is the `linux-gcc` job that runs the test suite twice, 2nd time with `GIT_TEST_ADD_I_USE_BUILTIN=1`). And that's on Linux. On Windows, not even running any other tests in parallel (i.e. unlike the `linux-gcc` job), the difference is 1m23s vs 39s on my beefy laptop. That's how slow Perl is. Imagine how much faster the entire test suite would run, for every developer, if we didn't use Perl (nor Bash, for that matter). This is not theoretical. There were, and are, instances of contributions which obviously did not run through the test suite before being submitted. I suspect that it simply takes too long. Ciao, Dscho
