Re: [PATCH v6 00/15] cmake: document, fix on *nix, add CI

From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: phillip.wood@dunelm.org.uk
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Victoria Dye <vdye@github.com>,
	Eric Sunshine <ericsunshine@gmail.com>
Subject: Re: [PATCH v6 00/15] cmake: document, fix on *nix, add CI
Date: Thu, 08 Dec 2022 01:06:07 +0100	[thread overview]
Message-ID: <221208.865yem91ya.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <b56d6f29-b22f-f64a-82b3-e7217c0e720d@dunelm.org.uk>

On Wed, Dec 07 2022, Phillip Wood wrote:

> Hi Ævar
>
> On 06/12/2022 02:08, Ævar Arnfjörð Bjarmason wrote:
>> This topic gets our tests from passing ~80% with ctest on *nix to
>> passing 100%.
>> See passing CI job for "cmake + ctest" on Ubuntu at:
>> https://github.com/avar/git/actions/runs/3625189647
>> See
>> https://lore.kernel.org/git/cover-v5-00.15-00000000000-20221202T110947Z-avarab@gmail.com/
>> for the v5.
>> Changes since v5:
>> * Typo/grammar etc. fixes noted by Eric.
>> * Phillip reported the "chmod" fallback no working on Windows. I
>>    couldn't reproduce that, but running it was always redundant there
>>    we'll now skip doing that on Windows.
>
> I suspect the issue is that "chmod" is not in %path% (i.e. $PATH in
> posix shell speak) when CMake is run from visual studio (the mingw
> stuff is only available when running "sh" by default to prevent name
> clashes with the windows find command etc.) but is added to $PATH in
> the CI after installing the git-for-windows sdk.

Maybe, presumably the "sh" then sets the $PATH, because we do run
shellscripts at the top-level that expect to find the binutils,
e.g. "sed" and the like, which presumably are in the same location as
"chmod".

But in any case this v6 avoids the issue entirely.

>> * Adjust 15/15 to fold into an existing "case" statement, rather than
>>    adding a new "if" statement.
>> For this v6 I experimented with changing the "win+VS build|test" job
>> build in "contrib/buildsystems/out" rather than at the top-level[1]. I
>> left those changes out here, but doing so makes that a lot simpler, as
>> it no longer needs to rely on the Makefile to tell it what cmake might
>> have built.
>
> Long term I think that is a good direction for the CI job. The CI job
> is not a good simulation of running CMake from Visual Studio.

Yes, I just didn't want to make this series even larger, but I can
submit that after.

> That does not normally matter but has been a problem for this
> series. Ideally it would run the test with CTest as well, I'm not sure
> how much work that would be.

In principle trivial, I did try, but it seems the Windows image doesn't
have "ctest", but does have "cmake" (unlike the Ubuntu image).

(Or come to think of it, maybe it does and I tried "ctest" and not
"ctest.exe". I can't remember)

Other than that it should just work, and the "linux-cmake-ctest" CI job
added by this series already does a run with "ctest".

>> But even without including that here, those changes should give more
>> confidence in these changes, i.e. they show that our CI's "msbuild"
>> doesn't require the "cmake" to build things at the top-level.
>> 1. https://github.com/avar/git/tree/avar/cmake-test-path-no-make-for-windows-ci
>> Ævar Arnfjörð Bjarmason (15):
>>    cmake: don't invoke msgfmt with --statistics
>>    cmake: use "-S" and "-B" to specify source and build directories
>>    cmake: update instructions for portable CMakeLists.txt
>>    cmake: don't copy chainlint.pl to build directory
>>    cmake: chmod +x the bin-wrappers/* & SCRIPT_{SH,PERL} & git-p4
>>    cmake & test-lib.sh: add a $GIT_SOURCE_DIR variable
>>    cmake: set "USE_LIBPCRE2" in "GIT-BUILD-OPTIONS" for test-lib.sh
>>    Makefile + test-lib.sh: don't prefer cmake-built to make-built git
>
> As far as I can see this changes test-lib.sh to prefer the make-built
> git if it exists even after running cmake and ctest. Ideally we'd test 
> the most recent build.

Ideally, but as summarized in the v5 CL this already isn't the case on
"master". I.e. you can e.g. build with cmake, then "make git", then your
tests will use the cmake (older) git, not your newly built one with
"make".

I think the only sane state of affairs here is what this series changes
it to.

If we have a top-level "git" we should always prefer it, as "make" is
our primary build system, and it would be impractical to plug all the
gaps and intercept the "latest git" in all places.

But more importantly, isn't this concern entirely academic?

We can imagine scenarios where you build with both, but the VS users
that are the primary audience of the cmake recipe aren't going to also
build with "make", they're just building with "cmake" and "msbuild".

So I don't think this will impact anyone in practice.

Even you have both a "make" and "cmake" build in play the "make test"
and "ctest" will always select the "make" and "cmake" built one,
respectively.

The only case where we need to pick one is if you run a test manually by
cd-ing to "t" and invoking a shellscript.

You also brought up a concern about multiple builds in
contrib/buildsystems/ in a previous iteration. With the way this series
leaves it that'll actually work in some sensible way. I.e. your "ctest"
run for a "prod" build run won't switch to a new git that you built
midway through the run, as it would on "master".