Re: [PATCH v3 1/5] cmake: make it easier to diagnose regressions in CTest runs

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Oct 18 2022, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When a test script fails in Git's test suite, the usual course of action
> is to re-run it using options to increase the verbosity of the output,
> e.g. `-v` and `-x`.
>
> Like in Git's CI runs, when running the tests in Visual Studio via the
> CTest route, it is cumbersome or at least requires a very unintuitive
> approach to pass options to the test scripts: the CMakeLists.txt file
> would have to be modified, passing the desired options to _all_ test
> scripts, and then the CMake Cache would have to be reconfigured before
> running the test in question individually. Unintuitive at best, and
> opposite to the niceties IDE users expect.
>
> So let's just pass those options by default: This will not clutter any
> output window but the log that is written to a log file will have
> information necessary to figure out test failures.
>
> While at it, also imitate what the Windows jobs in Git's CI runs do to
> accelerate running the test scripts: pass the `--no-bin-wrappers` and
> `--no-chain-lint` options.
>
> This makes the test runs noticeably faster because the `bin-wrappers/`
> scripts as well as the `chain-lint` code make heavy use of POSIX shell
> scripting, which is really, really slow on Windows due to the need to
> emulate POSIX behavior via the MSYS2 runtime. In a test by Eric
> Sunshine, it added two minutes (!) just to perform the chain-lint task.
>
> The idea of adding a CMake config option (á la `GIT_TEST_OPTS`) was
> considered during the development of this patch, but then dropped: such
> a setting is global, across _all_ tests, where e.g. `--run=...` would
> not make sense. Users wishing to override these new defaults are better
> advised running the test script manually, in a Git Bash, with full
> control over the command line.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  contrib/buildsystems/CMakeLists.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
> index 2237109b57f..6ac20bc5054 100644
> --- a/contrib/buildsystems/CMakeLists.txt
> +++ b/contrib/buildsystems/CMakeLists.txt
> @@ -1088,7 +1088,7 @@ file(GLOB test_scipts "${CMAKE_SOURCE_DIR}/t/t[0-9]*.sh")
>  #test
>  foreach(tsh ${test_scipts})
>  	add_test(NAME ${tsh}
> -		COMMAND ${SH_EXE} ${tsh}
> +		COMMAND ${SH_EXE} ${tsh} --no-bin-wrappers --no-chain-lint -vx
>  		WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/t)
>  endforeach()

This all seems sensible, but where you lose me is why this needs to be
cmake-specific.

Maybe I'm just missing something, but everything you're describing seems
to me to be Windows-specific, e.g. "chain lint is slow on windows" and
the like.

Why aren't we just declaring that it's not worth it on Windows, but
doing so in test-lib.sh, or at least doing it in both cmake's recipe &
the Makefile?

I can see why we'd e.g. want it not to run with "make test", but want it
when you run individual tests, but then both could just set some "this
is running as a batch" env flag or whatever.

Also, even then everything you're describing is eliding that:

 - This ill makes sense for Windows, sure, but the cmake recipe is no
   longer Windows-specific, was this authored before that happened &
   rebased? Why do we want cmake/ctest on Linux to have --no-chain-lint?

 - Having cmake be some "mostly the Makefile, but also other defaults"
   is really changing the scope of the whole cmake build alternative,
   which until now (but I may have missed some other special-cases) has
   been "let's build it like the Makefile".

 - That "ctest" doesn't work on Linux *at all* currently, this fixes it,
   but is really sweeping the underlying issue under the rug. AFAICT
   it's been limping along because there's no "chmod +x" or whatever on
   Windows (IIRC we magically look at she shebang).

For that last one & more I hacked up
https://github.com/avar/git/tree/avar/cmake-test-path a few days ago as
an alternative to some parts of this series, but given past exchanges
wanted to ask you first what you thought about it off-list, but didn't
get around to it..

But anyway, I do think starting with something like
https://github.com/avar/git/commit/5bd0ee2bc826d2bb358af9d93c88ba28584bbda1
makes more sense, i.e. get "ctest" to work at all with the
bin-wrappers/* in a portable way, and then *maybe* tweak it/Makefile to
pass some custom flags on some platform(s).