patch, 3 partscmake: add knob to disable vcpkg

> 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.

>
> On Fri, Jun 4, 2021 at 1:44 PM Matthew Rogers via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> > 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.
>
> 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.
>

> >   - 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/
>
> > Signed-off-by: Matthew Rogers <mattr94@gmail.com>

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

>
> On Fri, Jun 4, 2021 at 11:13 PM Matthew Rogers via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>
> > -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

>
> On Fri, Jun 4, 2021 at 4:55 PM Sibi Siddharthan
> <sibisiddharthan.github@gmail.com> wrote:
> >
> > On Fri, Jun 4, 2021 at 11:13 PM Matthew Rogers via GitGitGadget
> > <gitgitgadget@gmail.com> wrote:
> >
> > > -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)
>
> 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)
>

> 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.

>
> 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.
>

>
> On Fri, Jun 4, 2021 at 11:13 PM Matthew Rogers via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> >
> > 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.
> >
>
> The overhead is actually much smaller than that. In my system it is
> less than 150ms.

>
> On Fri, Jun 4, 2021 at 5:09 PM Sibi Siddharthan
> <sibisiddharthan.github@gmail.com> wrote:
> >
> > On Fri, Jun 4, 2021 at 11:13 PM Matthew Rogers via GitGitGadget
> > <gitgitgadget@gmail.com> wrote:
> > >
> > > 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.
> > >
> >
> > 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.

>
> Hi,
>
> On 05/06/21 00.43, Matthew Rogers via GitGitGadget wrote:
> > 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

> On 05/06/21 00.43, Matthew Rogers via GitGitGadget wrote:
> > 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.

> Hi,
>
> On Sat, 5 Jun 2021, Bagas Sanjaya wrote:
>
>> On 05/06/21 00.43, Matthew Rogers via GitGitGadget wrote:
>>> 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.
> 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.

> On 10/06/2021 10:43, Johannes Schindelin wrote:
> >
> > On Sat, 5 Jun 2021, Bagas Sanjaya wrote:
> >
> >> 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`).
>
> 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 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.
>
>

> On 18/06/2021 14:42, Johannes Schindelin wrote:
> >>> 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.
> >
> >
> 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).

> 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
> philipoakley@iee.email cc: Sibi Siddharthan
> sibisiddharthan.github@gmail.com, cc: Johannes Schindelin
> johannes.schindelin@gmx.de, cc: Danh Doan congdanhqx@gmail.com
>
> Matthew Rogers (3):
>   cmake: add knob to disable vcpkg
>   cmake: create compile_commands.json by default
>   cmake: add warning for ignored MSGFMT_EXE

> "Matthew Rogers via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > 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
> > philipoakley@iee.email cc: Sibi Siddharthan
> > sibisiddharthan.github@gmail.com, cc: Johannes Schindelin
> > johannes.schindelin@gmx.de, cc: Danh Doan congdanhqx@gmail.com
> >
> > 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 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
>

> As long as the CI builds pass, I am in favor of integrating the patch
> series.
>
>> 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.

> "Matthew Rogers via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> 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
>> philipoakley@iee.email cc: Sibi Siddharthan
>> sibisiddharthan.github@gmail.com, cc: Johannes Schindelin
>> johannes.schindelin@gmx.de, cc: Danh Doan congdanhqx@gmail.com
>>
>> 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'.

> 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
> philipoakley@iee.email cc: Sibi Siddharthan
> sibisiddharthan.github@gmail.com, cc: Johannes Schindelin
> johannes.schindelin@gmx.de, cc: Danh Doan congdanhqx@gmail.com

>
> 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 <mattr94@gmail.com>
>      @@ 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 <mattr94@gmail.com>
>
>        ## 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 <johannes.schindelin@gmx.de>
>      +    Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>           Signed-off-by: Matthew Rogers <mattr94@gmail.com>
>
>        ## 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
>