Make CMake work out of the box

When building on windows users have the option to use vcpkg to provide the dependencies needed to compile. Previously, this was used only when using the Visual Studio generator which was not ideal because:

- Not all users who want to use vcpkg use the Visual Studio generators.

- Some versions of Visual Studio 2019 moved away from using the VS 2019 by default, making it impossible for Visual Studio to configure the project in the likely event that it couldn't find the dependencies.

- Inexperienced users of CMake are very likely to get tripped up by the errors caused by a lack of vcpkg, making the above bullet point both annoying and hard to debug.

As such, lets make using vcpkg the default on windows. Users who want to avoid using vcpkg can disable it by passing -DNO_VCPKG=TRUE.

Signed-off-by Matthew Rogers <[email protected]>

Some users have expressed interest in a more "batteries included" way of building via CMake[1], and a big part of that is providing easier access to tooling external tools.

A straightforward way to accomplish this is to make it as simple as possible is to enable the generation of the compile_commands.json file, which is supported by many tools such as: clang-tidy, clang-format, sourcetrail, etc.

This does come with a small run-time overhead during the configuration step (~6 seconds on my machine):

    [...]

This seems like a small enough price to pay to make the project more accessible to newer users. Additionally there are other large projects like llvm [2] which has had this enabled by default for >6 years at the time of this writing, and no real negative consequences that I can find with my search-skills.

NOTE: That the comppile_commands.json is currenntly produced only when using the Ninja and Makefile generators. See The CMake documentation[3] for more info.

Signed-off-by Matthew Rogers <[email protected]>

It does not make sense to attempt to set MSGFMT_EXE when NO_GETTEXT is configured, as such add a check for NO_GETTEXT before attempting to set it.

suggested-by Johannes Schindelin <[email protected]>

Signed-off-by Matthew Rogers <[email protected]>

Quoted 7 lines · Matthew Rogers via GitGitGadget

When building on windows users have the option to use vcpkg to provide the dependencies needed to compile. Previously, this was used only when using the Visual Studio generator which was not ideal because:

- Not all users who want to use vcpkg use the Visual Studio generators.

Quoted 4 lines

- Some versions of Visual Studio 2019 moved away from using the VS 2019 by default, making it impossible for Visual Studio to configure the project in the likely event that it couldn't find the dependencies.

Is there something missing between "using the" and "VS 2019"? I'm having a hard time trying to understand what this bullet point is saying due to this apparent gap.

Quoted 6 lines

- Inexperienced users of CMake are very likely to get tripped up by the errors caused by a lack of vcpkg, making the above bullet point both annoying and hard to debug.

As such, lets make using vcpkg the default on windows. Users who want to avoid using vcpkg can disable it by passing -DNO_VCPKG=TRUE.

s/lets/let's/

Quoted 1 line

Signed-off-by Matthew Rogers <[email protected]>

A straightforward way to accomplish this is to make it as simple as possible is to enable the generation of the compile_commands.json file, which is supported by many tools such as: clang-tidy, clang-format, sourcetrail, etc.

This does come with a small run-time overhead during the configuration step (~6 seconds on my machine):

    Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=TRUE

    real    1m9.840s
    user    0m0.031s
    sys     0m0.031s

    Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=FALSE

    real    1m3.195s
    user    0m0.015s
    sys     0m0.015s

This seems like a small enough price to pay to make the project more accessible to newer users. Additionally there are other large projects like llvm [2] which has had this enabled by default for >6 years at the time of this writing, and no real negative consequences that I can find with my search-skills.

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion.

contrib/buildsystems/CMakeLists.txt NOTE: By default CMake uses Makefile as the build tool on Linux and Visual Studi · line 59

Quoted 7 lines · Matthew Rogers via GitGitGadget

contrib/buildsystems/CMakeLists.txt +6 -1

-if(WIN32)
+
+if (WIN32 AND NOT NO_VCPKG)
+       set(USING_VCPKG TRUE)
+else()
+       set(USING_VCPKG FALSE)
+endif()

I think it would be better if we could have an option for this knob. Maybe like this

option(NO_VCPKG "Don't use vcpkg for obtaining dependencies. Only applicable to Windows platforms" OFF)

I would prefer to use USE_VCPKG.

Thank You,
Sibi Siddharthan

Quoted 21 lines · Matthew Rogers via GitGitGadget

A straightforward way to accomplish this is to make it as simple as possible is to enable the generation of the compile_commands.json file, which is supported by many tools such as: clang-tidy, clang-format, sourcetrail, etc.

This does come with a small run-time overhead during the configuration step (~6 seconds on my machine):

    Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=TRUE

    real    1m9.840s
    user    0m0.031s
    sys     0m0.031s

    Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=FALSE

    real    1m3.195s
    user    0m0.015s
    sys     0m0.015s

Quoted 6 lines

This seems like a small enough price to pay to make the project more accessible to newer users. Additionally there are other large projects like llvm [2] which has had this enabled by default for >6 years at the time of this writing, and no real negative consequences that I can find with my search-skills.

The overhead is actually much smaller than that. In my system it is less than 150ms.

The first configure takes this long because we generate command-list.h and config-list.h.
This process is really slow under Windows.

Thank You,
Sibi Siddharthan

Hi,

Quoted 7 lines · Matthew Rogers via GitGitGadget

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion.

This focused on improving CMake support, especially on Visual Studio, right?

Then so we have three ways to build Git:
1. plain Makefile
2. ./configure (really just wrapper on top of Makefile)
3. generate build file with CMake

If we want to support all of them, it may makes sense to have CI jobs that perform build with each options above.

--
An old man doll... just what I always wanted! - Clara

Quoted 15 lines · Sibi Siddharthan

contrib/buildsystems/CMakeLists.txt NOTE: By default CMake uses Makefile as the build tool on Linux and Visual Studi · line 59

Quoted 7 lines · Matthew Rogers via GitGitGadget

contrib/buildsystems/CMakeLists.txt +6 -1

-if(WIN32)
+
+if (WIN32 AND NOT NO_VCPKG)
+       set(USING_VCPKG TRUE)
+else()
+       set(USING_VCPKG FALSE)
+endif()

I think it would be better if we could have an option for this knob. Maybe like this

Quoted 2 lines

option(NO_VCPKG "Don't use vcpkg for obtaining dependencies. Only applicable to Windows platforms" OFF)

Option would definitely be the better tool to use here, I just didn't think about
it when originally writing it, so I'll send a reroll with that and the spelling corrections suggested by Eric Sunshine. I assume you'd prefer something with a final form more like:

option(USE_VCPKG "Whether or not to use vcpkg for obtaining dependencies. Only applicable to Windows platforms" ON)

Quoted 31 lines · Sibi Siddharthan

Quoted 27 lines · Matthew Rogers via GitGitGadget

A straightforward way to accomplish this is to make it as simple as possible is to enable the generation of the compile_commands.json file, which is supported by many tools such as: clang-tidy, clang-format, sourcetrail, etc.

This does come with a small run-time overhead during the configuration step (~6 seconds on my machine):

    Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=TRUE

    real    1m9.840s
    user    0m0.031s
    sys     0m0.031s

    Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=FALSE

    real    1m3.195s
    user    0m0.015s
    sys     0m0.015s

This seems like a small enough price to pay to make the project more accessible to newer users. Additionally there are other large projects like llvm [2] which has had this enabled by default for >6 years at the time of this writing, and no real negative consequences that I can find with my search-skills.

Quoted 2 lines

The overhead is actually much smaller than that. In my system it is less than 150ms.

Is that 150 ms for the whole process or just the difference between the two options? I'm running this on windows via the git bash provided by the git sdk.

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion. cc: Philip Oakley [email protected] cc: Sibi Siddharthan [email protected], cc: Johannes Schindelin [email protected], cc: Danh Doan [email protected]

Matthew Rogers (3):
cmake: add knob to disable vcpkg
cmake: create compile_commands.json by default
cmake: add warning for ignored MSGFMT_EXE

Quoted 7 lines · Matthew Rogers via GitGitGadget

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion.

This focused on improving CMake support, especially on Visual Studio, right?

Then so we have three ways to build Git:
1. plain Makefile
2. ./configure (really just wrapper on top of Makefile)
3. generate build file with CMake

If we want to support all of them, it may makes sense to have CI jobs that perform build with each options above.

Quoted 11 lines · Matthew Rogers via GitGitGadget

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion. cc: Philip Oakley [email protected] cc: Sibi Siddharthan [email protected], cc: Johannes Schindelin [email protected], cc: Danh Doan [email protected]

Quoted 4 lines

Matthew Rogers (3):
cmake: add knob to disable vcpkg
cmake: create compile_commands.json by default
cmake: add warning for ignored MSGFMT_EXE

I am neither cmake nor windows person, so I'll queue this as-is and wait for the stakeholders to chime in.

I did wonder if we want this to be applicable to the maintenance track for 2.31, though. There is a textual conflict with the addition of SIMPLE_IPC that happened during 2.32 cycle, which is easily resolvable.

I am tempted to queue a version of these three patches rebased on to 'maint' after making sure that the result of merging that into 'master' is byte-for-byte identical to applying these three patches directly on to 'master'.

The range-diff looks like the attached. Thanks.

1: 546c49cc88 ! 1: 585b7ca371 cmake: add knob to disable vcpkg

    @@ contrib/buildsystems/CMakeLists.txt: endif()
      	if(NOT EXISTS ${MSGFMT_EXE})
      		message(WARNING "Text Translations won't be built")
      		unset(MSGFMT_EXE)
    -@@ contrib/buildsystems/CMakeLists.txt: file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "X='${EXE_EXTENSION}'\n")
    - file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_GETTEXT='${NO_GETTEXT}'\n")
    +@@ contrib/buildsystems/CMakeLists.txt: file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_GETTEXT='${NO_GETTEXT}'\n"
      file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "RUNTIME_PREFIX='${RUNTIME_PREFIX}'\n")
      file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PYTHON='${NO_PYTHON}'\n")
    + file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "SUPPORTS_SIMPLE_IPC='${SUPPORTS_SIMPLE_IPC}'\n")
     -if(WIN32)
     +if(USE_VCPKG)
      	file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
2:  efa8681a22 = 2:  1cba2f9bd1 cmake: create compile_commands.json by default
3:  ceeca2bc0d = 3:  7824e74976 cmake: add warning for ignored MSGFMT_EXE

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion. cc: Philip Oakley [email protected] cc: Sibi Siddharthan [email protected], cc: Johannes Schindelin [email protected], cc: Danh Doan [email protected]

Matthew Rogers (3):
cmake: add knob to disable vcpkg
cmake: create compile_commands.json by default
cmake: add warning for ignored MSGFMT_EXE

 contrib/buildsystems/CMakeLists.txt | 37 ++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 9 deletions(-)

base-commit: c09b6306c6ca275ed9d0348a8c8014b2ff723cfb
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-970%2FROGERSM94%2Ffix-cmake-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-970/ROGERSM94/fix-cmake-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/970

Range-diff vs v1:

1: 3170f78daa5f ! 1: 485254b49de8 cmake: add knob to disable vcpkg

     @@ Commit message
              generators.

            - Some versions of Visual Studio 2019 moved away from using the
     -        VS 2019 by default, making it impossible for Visual Studio to
     -        configure the project in the likely event that it couldn't find the
     -        dependencies.
     +        VS 2019  generator by default, making it impossible for Visual
     +        Studio to configure the project in the likely event that it couldn't
     +        find the dependencies.

            - Inexperienced users of CMake are very likely to get tripped up by
              the errors caused by a lack of vcpkg, making the above bullet point
              both annoying and hard to debug.

     -    As such, lets make using vcpkg the default on windows.  Users who want
     +    As such, let's make using vcpkg the default on windows.  Users who want
          to avoid using vcpkg can disable it by passing -DNO_VCPKG=TRUE.

          Signed-off-by: Matthew Rogers <[email protected]>
     @@ contrib/buildsystems/CMakeLists.txt: NOTE: By default CMake uses Makefile as the
       set(CMAKE_SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../..)
      -if(WIN32)
      +
     -+if (WIN32 AND NOT NO_VCPKG)
     -+	set(USING_VCPKG TRUE)
     -+else()
     -+	set(USING_VCPKG FALSE)
     ++option(USE_VCPKG "Whether or not to use vcpkg for obtaining dependencies.  Only applicable to Windows platforms" ON)
     ++if(NOT WIN32)
     ++	set(USE_VCPKG OFF CACHE BOOL FORCE)
      +endif()
      +
     -+if(USING_VCPKG)
     ++if(USE_VCPKG)
       	set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg")
      -	if(MSVC AND NOT EXISTS ${VCPKG_DIR})
      +	if(NOT EXISTS ${VCPKG_DIR})
     @@ contrib/buildsystems/CMakeLists.txt: endif()
       find_program(MSGFMT_EXE msgfmt)
       if(NOT MSGFMT_EXE)
      -	set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
     -+	if (USING_VCPKG)
     ++	if (USE_VCPKG)
      +		set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
      +	endif()
       	if(NOT EXISTS ${MSGFMT_EXE})
     @@ contrib/buildsystems/CMakeLists.txt: file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-O
       file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "NO_PYTHON='${NO_PYTHON}'\n")
       file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "SUPPORTS_SIMPLE_IPC='${SUPPORTS_SIMPLE_IPC}'\n")
      -if(WIN32)
     -+if(USING_VCPKG)
     ++if(USE_VCPKG)
       	file(APPEND ${CMAKE_BINARY_DIR}/GIT-BUILD-OPTIONS "PATH=\"$PATH:$TEST_DIRECTORY/../compat/vcbuild/vcpkg/installed/x64-windows/bin\"\n")
       endif()

2: c3bf266cf03a ! 2: a3b5eef54188 cmake: create compile_commands.json by default
@@ Commit message
time of this writing, and no real negative consequences that I can find with my search-skills.

- NOTE: That the comppile_commands.json is currenntly produced only when
+ NOTE: That the compile_commands.json is currently produced only when
using the Ninja and Makefile generators. See The CMake documentation[3] for more info.

@@ Commit message

Signed-off-by Matthew Rogers <[email protected]>

## contrib/buildsystems/CMakeLists.txt ##
-@@ contrib/buildsystems/CMakeLists.txt: else()
- set(USING_VCPKG FALSE)
+@@ contrib/buildsystems/CMakeLists.txt: if(NOT WIN32)
+ set(USE_VCPKG OFF CACHE BOOL FORCE)
endif()

-+if (NOT DEFINED CMAKE_EXPORT_COMPILE_COMMANDS)
-+ SET(CMAKE_EXPORT_COMPILE_COMMANDS TRUE)
++if(NOT DEFINED CMAKE_EXPORT_COMPILE_COMMANDS)
++ set(CMAKE_EXPORT_COMPILE_COMMANDS TRUE)
+endif()
+
- if(USING_VCPKG)
+ if(USE_VCPKG)
set(VCPKG_DIR "${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg") if(NOT EXISTS ${VCPKG_DIR})
3: 07763a9de723 ! 3: 2110c8ffa423 cmake: add warning for ignored MSGFMT_EXE

     @@ Commit message
          configured, as such add a check for NO_GETTEXT before attempting to set
          it.

     -    suggested-by: Johannes Schindelin <[email protected]>
     +    Suggested-by: Johannes Schindelin <[email protected]>
          Signed-off-by: Matthew Rogers <[email protected]>

       ## contrib/buildsystems/CMakeLists.txt ##
     @@ contrib/buildsystems/CMakeLists.txt: if(WIN32 AND NOT MSVC)#not required for vis

      -find_program(MSGFMT_EXE msgfmt)
      -if(NOT MSGFMT_EXE)
     --	if (USING_VCPKG)
     +-	if (USE_VCPKG)
      -		set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
      -	endif()
      -	if(NOT EXISTS ${MSGFMT_EXE})
     @@ contrib/buildsystems/CMakeLists.txt: if(WIN32 AND NOT MSVC)#not required for vis
      +else()
      +	find_program(MSGFMT_EXE msgfmt)
      +	if(NOT MSGFMT_EXE)
     -+		if (USING_VCPKG)
     ++		if(USE_VCPKG)
      +			set(MSGFMT_EXE ${CMAKE_SOURCE_DIR}/compat/vcbuild/vcpkg/downloads/tools/msys2/msys64/usr/bin/msgfmt.exe)
      +		endif()
      +		if(NOT EXISTS ${MSGFMT_EXE})

--
gitgitgadget

Just in case that a v3 is needed, I fixed the PR description so that these "Cc:"s are interpreted correctly again by GitGitGadget.

But from a brief glance over v2, all patches look good to me.

Hi,

Quoted 8 lines · Bagas Sanjaya

Quoted 7 lines · Matthew Rogers via GitGitGadget

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion.

Quoted 9 lines

This focused on improving CMake support, especially on Visual Studio, right?

Then so we have three ways to build Git:
1. plain Makefile
2. ./configure (really just wrapper on top of Makefile)
3. generate build file with CMake

If we want to support all of them, it may makes sense to have CI jobs that perform build with each options above.

We already exercise the plain Makefile plenty, and the CMake-based build using Windows (in the vs-build job in .github/workflows/main.yml).

I do not see that it is worth spending many electrons exercising the ./configure way, seeing as the preferred way to build Git is by using the Makefile directly.

And our CMake configuration only really works on Windows, the attempts to get it to work on Linux were met with less enthusiasm, seeing as the Makefile approach is the recommended (and supported) one.

tl;dr I don't think we need to augment our CI jobs as suggested.

Quoted 11 lines · Matthew Rogers via GitGitGadget

This pull request comes from our discussion here[1], and I think these patches provide a good compromise around the concerns discussed there

1:
https://lore.kernel.org/git/CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com/

CCing the people involved in the original discussion. cc: Philip Oakley [email protected] cc: Sibi Siddharthan [email protected], cc: Johannes Schindelin [email protected], cc: Danh Doan [email protected]

Quoted 4 lines

Matthew Rogers (3):
cmake: add knob to disable vcpkg
cmake: create compile_commands.json by default
cmake: add warning for ignored MSGFMT_EXE

I am neither cmake nor windows person, so I'll queue this as-is and wait for the stakeholders to chime in.

I did wonder if we want this to be applicable to the maintenance track for 2.31, though. There is a textual conflict with the addition of SIMPLE_IPC that happened during 2.32 cycle, which is easily resolvable.

I am tempted to queue a version of these three patches rebased on to 'maint' after making sure that the result of merging that into 'master' is byte-for-byte identical to applying these three patches directly on to 'master'.

As long as the CI builds pass, I am in favor of integrating the patch series.

Quoted 4 lines

I did wonder if we want this to be applicable to the maintenance track for 2.31, though. There is a textual conflict with the addition of SIMPLE_IPC that happened during 2.32 cycle, which is easily resolvable.

If it isn't much work, sure. But I would think that developers who want to build using Visual Studio really should stay on newer branches.

Quoted 10 lines · Johannes Schindelin

Quoted 7 lines · Bagas Sanjaya

This focused on improving CMake support, especially on Visual Studio, right?

Then so we have three ways to build Git:
1. plain Makefile
2. ./configure (really just wrapper on top of Makefile)
3. generate build file with CMake

Quoted 5 lines

Quoted 2 lines

If we want to support all of them, it may makes sense to have CI jobs that perform build with each options above.

We already exercise the plain Makefile plenty, and the CMake-based build using Windows (in the vs-build job in .github/workflows/main.yml).

There is one 'gotcha' in the yml (probably historical) in that it doesn't actually test the approach/changes that Matt addresses regarding my [1].

That is, I'm looking at the 'out of the box' view, while the yml test _preloads_ the vcpkg artefacts.

Quoted 8 lines

Quoted 2 lines

We already exercise the plain Makefile plenty, and the CMake-based build using Windows (in the vs-build job in .github/workflows/main.yml).

There is one 'gotcha' in the yml (probably historical) in that it doesn't actually test the approach/changes that Matt addresses regarding my [1].

That is, I'm looking at the 'out of the box' view, while the yml test _preloads_ the vcpkg artefacts.

We need to "pre-load" them because building them would add another whopping 20 minutes to each CI run. And I am not talking total time, but wall-clock time.

And we're not in the business of testing vcpkg's build.

So I am really not in favor of even thinking about changing this "pre-loading" strategy.

Quoted 8 lines · Johannes Schindelin

Quoted 8 lines

Quoted 2 lines

We already exercise the plain Makefile plenty, and the CMake-based build using Windows (in the vs-build job in .github/workflows/main.yml).

There is one 'gotcha' in the yml (probably historical) in that it doesn't actually test the approach/changes that Matt addresses regarding my [1].

That is, I'm looking at the 'out of the box' view, while the yml test _preloads_ the vcpkg artefacts.

Quoted 10 lines

We need to "pre-load" them because building them would add another whopping 20 minutes to each CI run. And I am not talking total time, but wall-clock time.

And we're not in the business of testing vcpkg's build.

So I am really not in favor of even thinking about changing this "pre-loading" strategy.

I can see the common sense in that, however I was trying to highlight that the approach in patch series could go stale, as did the previous method. Making the entry ramp to investigating the code for the wide variety windows users should have _some_ testing..

I don't have any good ideas about how to get out of that 20 minute Catch-22 issue at the moment. Maybe it needs an independent, on-demand (i.e. infrequent;-) test.

Maybe there is a way of adding a --CI-test option that at least exercises the logic without needing the vcpkg to be built again (IIRC, and I may well be wrong, we build once, remember the artefacts, and then re-used them, but .. dunno).