Compilation of envoy 1.29.0 on Windows Server 2022 feedback

[Aorimn]

Title: Compilation of envoy 1.29.0 on Windows Server 2022 feedback

Description:
I managed to compile envoy 1.29.0 from the release archive on a Windows Server 2022 machine, with some quirks. I just wanted to provide those quirks so that envoy developers can know about them (then it's your decision to somehow fix them or not).

Repro steps:
I followed this documentation on building envoy with Bazel. After installing Bazel, I quickly jumped to the Windows section.

bazel.bazelrc (if relevant):

startup --output_base=C:/_eb --windows_enable_symlinks
build --enable_runfiles

Quirk 1: MSYS2 & VS 2019 build tools installation order
If you follow the documentation and install line by line, when installing VS 2019 for the build tools, you encounter this note:

NOTE: ensure that the link.exe that resolves on your PATH is from VC++ Build Tools and not /usr/bin/link.exe from MSYS2, which is determined by their relative ordering in your PATH

This means that after installing MSYS2, the following command is a trap:

set PATH=%USERPROFILE%\msys64\usr\bin;%PATH%

Setting the path once for both of those installs obviously fixes the issue:

set PATH=%USERPROFILE%\VSBT2019\VC\Tools\MSVC\14.26.28801\bin\Hostx64\x64;%USERPROFILE%\msys64\usr\bin;%PATH%

But you could also choose to put MSYS2 at the end of the path (which I did, because I already changed my PATH when reading/understanding this). This will lead to the following error during compilation:

FIND: Parameter format not correct

find.exe from C:\Windows\System32 is being used instead of the one from MSYS2.

I didn't test, but maybe just switching both the "Build Tools for Visual Studio 2019" and "MSYS2 shell" paragraphs would avoid such meagre trouble.

Quirk 2: SOURCE_VERSION file
I used the 1.29.0 source code zip to build this envoy (maybe that's already a mistake in itself, please let me know). I soon encountered an issue with the SOURCE_VERSION file not being found. Thankfully this issue helps, but I'm wondering why this PR doesn't prevent this issue from happening already.

The most troubling thing with this one is that having the file suffice it to build (I put "1.29.0" in there initially). However, it creates a runtime error (depending on the configuration I assume). Isn't it something that could be checked at build time?

Anyway, a quick look at https://api.github.com/repos/envoyproxy/envoy/commits/v1.29.0 and its "sha" entry and we're back on track.

Quirk 3: Perfetto / traced_value.h
Upon building envoy, I got an error telling me the C:_eb\external\com_googlesource_googleurl\polyfills\third_party\perfetto\include\perfetto\tracing\traced_value.h file didn't know the identifier string. Googling around, I added #include <string> right after the include guard, re-ran the compilation and this time it passed.

I don't know how bazel works, to be fully transparent, but googling around again, I'm seeing this file which doesn't have the said include whereas this one has.

Is there any reference somewhere to be changed to the "new perfetto repo" (assuming the one on github is the newest version)?

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.