Windows compile with CMake fails - Can't find googletest or nlohmann_json

[BuildMan-Alpha]

Describe your environment
Windows VS 2019 (16.10.0)

Steps to reproduce
Clone repository with --recursive.
Run CMake with arguments -G "Visual Studio 16 2019" -A "x64" "-DBUILD_TESTING=OFF" "c:\dev\AA3rdPartyExt\opentelemetry-cpp" "-DCMAKE_TOOLCHAIN_FILE=C:\dev\vcpkg\scripts\buildsystems\vcpkg.cmake" -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DWITH_PROMETHEUS=ON

What is the expected behavior?
Clean compile

What is the actual behavior?
Build-CMake-Project-Windows : Error Invoking cmake to create the project files failed - level 1
Building with nostd types...
CMake Error at C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package):
By not providing "Findnlohmann_json.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"nlohmann_json", but CMake did not find one.
Could not find a package configuration file provided by "nlohmann_json"
with any of the following names:
nlohmann_jsonConfig.cmake
nlohmann_json-config.cmake
Add the installation prefix of "nlohmann_json" to CMAKE_PREFIX_PATH or set
"nlohmann_json_DIR" to a directory containing one of the above files. If
"nlohmann_json" provides a separate development package or SDK, be sure it
has been installed.

Additional context
I was able to work around this by cloning and building both googletest and nlohmann_json and setting the CMake CMAKE_PREFIX_PATH environment variable to the target path of the respective builds.

DCMAKE_PREFIX_PATH=c:\dev\AA3rdPartyExt\Build\nlohmann_json\VS16\Win64;c:\dev\AA3rdPartyExt\Build\googletest\VS16\Win64"

Note: It appears that the submodules were downloaded as per the log output below:
Processing project Open Telemetry from repository https://github.com/open-telemetry/opentelemetry-cpp in local folder c:\dev\AA3rdPartyExt\opentelemetry-cpp.
Cloning files from GitHub repository https://github.com/open-telemetry/opentelemetry-cpp into c:\dev\AA3rdPartyExt\opentelemetry-cpp
Submodule path 'third_party/benchmark': checked out 'c05843a9f622db08ad59804c190f98879b76beba'
Submodule path 'third_party/googletest': checked out 'a6dfd3aca7f2f91f95fc7ab650c95a48420d513d'
Submodule path 'third_party/ms-gsl': checked out '6f4529395c5b7c2d661812257cd6780c67e54afa'
Submodule path 'third_party/nlohmann-json': checked out 'db78ac1d7716f56fc9f1b030b715f872f93964e4'
Submodule path 'third_party/opentelemetry-proto': checked out '795cc815ce9bb438b46a4a7f6ecb465b52d50935'
Submodule path 'third_party/prometheus-cpp': checked out 'bb017ec15a824d3301845a1274b4b46a01d6d871'
Submodule path 'third_party/prometheus-cpp/3rdparty/civetweb': checked out '8e243456965c9be5212cb96519da69cd54550e3d'
Submodule path 'third_party/prometheus-cpp/3rdparty/googletest': checked out '703bd9caab50b139428cea1aaff9974ebee5742e'
Submodule path 'tools/vcpkg': checked out 'e9f8cc67a5e5541973e53ac03f88adb45cc1b21b'

[maxgolov]

@BuildMan-Alpha - could you please try this process:

https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/building-with-vs2019.md

Adjust the build files to your liking. I'm using this process daily. It works well.

Let me know your feedback.

[maxgolov]

This PR contains a few additional improvements to cover most compilers on Windows (vs2015-vs2019, recent versions of clang) :

#839

[BuildMan-Alpha]

Thanks Max! I will look closer at Ninja and the link you sent. From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Thursday, June 10, 2021 12:26 PM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) @BuildMan-Alpha <https://github.com/BuildMan-Alpha> - could you please try this process: https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/building-with-vs2019.md Adjust the build files to your liking. I'm using this process daily. It works well. Let me know your feedback. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJQ7VQY4FXS6S4FLSZLTSDRP5ANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJTLITFBZJFPQJ2LVR3TSDRP5A5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGMX3PII.gif>

[maxgolov]

Ninja Generator / build is x5 times faster. And produces the same output. The only scenario where you'd benefit from MSBuild -generated files, is if you want to debug the SDK in older Visual Studio 2017. I hope to get #839 merged, that cleans-up the overall build experience for all compilers - [vs2015|vs2017|vs2019|clang-*]. I will also validate the scripts for Win32 once we merge the fix for the other issue you reported. It should work well. Our main focus has been on x64 so far.

[BuildMan-Alpha]

Hi Max. With Ninja installed, I am able to get a build with x64 on windows. I still have to set the CMAKE_PREFIX_PATH variable to a previously downloaded folder for nlohmann_json for some reason. PR 839 didn’t seem to affect the Win32 build (assuming the error in circular_buffer.h is yet to be addressed). Using setup-buildtools.cmd and build.cmd work, but I would like to have this work with CMake because we are running a generic PowerShell script to clone/build/install and I’d like to avoid having to run other scripts. Thanks again! Kurt From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Friday, June 11, 2021 2:32 PM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) Ninja Generator / build is x5 times faster. And produces the same output. The only scenario where you'd benefit from MSBuild -generated files, is if you want to debug the SDK in older Visual Studio 2017. I hope to get #839 <#839> merged, that cleans-up the overall build experience for all compilers - [vs2015|vs2017|vs2019|clang-*]. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJS65H2OCYDHMLJNSPTTSJJDLANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJX3LXXEDC3TKG7NSTDTSJJDLA5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGM7PZVI.gif>

[maxgolov]

PR 839 didn’t seem to affect the Win32 build (assuming the error in circular_buffer.h is yet to be addressed).

Win32 error is being fixed in #847

[maxgolov]

@BuildMan-Alpha

Hi Kurt,

Win32 fix is now merged in the main. Please pull it and try building for Win32.

Re. CMAKE_PREFIX_PATH - this is interesting. We employ two (orthogonal) approaches:

• nlohmann json from vcpkg installation: scripts that I shared above would use a local snapshot of vcpkg package management. And inside that one we install vcpkg install nlohmann-json:%ARCH%-windows , which is x64 by default and may optionally be set to x86. CMake should be able to find it. I do not see the issue with Could not find a package configuration file provided by "nlohmann_json". As long as I run the installation before the build. I think when you run these scripts, your build is also successful?... albeit with ninja, but ninja is a technicality - it could have been MSBuild.

• nlohmann json from submodule: we also include a local snapshot of nlohmann json library, which you get in your workspace at third_party/nlohmann-json here , assuming you recursively cloned opentelemetry-cpp repository. Which appears like you did. There's one spot where we fallback to that submodule, assuming that your CMake installation (or vcpkg installation) did not provide the package. For example, piece of logic here - just uses the nlohmann json from submodule:
  

  opentelemetry-cpp/ext/test/w3c_tracecontext_test/CMakeLists.txt

  Line 7 in b073e8b

  find_package(nlohmann_json QUIET)

Perhaps we should improve our top-level CMakeLists.txt to fallback to local submodules, if customer's system does not have the package already installed.

Ultimately there is no right or wrong approach. What you are doing (providing your own dependency to CMake) - is also perfectly valid approach. Is this issue blocking you, would you consider adopting vcpkg as part of your build process on Windows (that'll give you some stable versions of GTest and nlohmann json)? Appears like you tested that this flow works okay. Or do you require specific versions of the packages? In that case what you are doing, providing your own dependencies - is the best thing to do.

[BuildMan-Alpha]

Hi Max, Great to hear Win32 is in the main branch! Running a test now. Ideally, I was hoping to just invoke CMake on an open source project and have all GitHub repositories it depends on built and install within the project. Setting up a build machine is tedious, and automating the installation really helps. As an old-school Visual Studio type, CMake is new to me, and I really like the concept and potential portability as we move to Windows/Linux/WSL builds. The gRPC team recommends using FetchContext_xxxx macros when including gRPC in a project and discourages installing gRPC globally as changing versions is “difficult”. Alas, the gRPC repository implementation itself has issues with FetchContent_xxxx macros for some dependencies, so I have had to learn a bit more than I expected about CMake… J CMAKE_PREFIX_PATH is something I stumbled on as a way to get at projects that are privately installed, and using it has gotten me past the CMake issues with OpenTelemetry (nlohmann_json and googletest). Yes, I had to clone, build and install both projects before OpenTelemetry and used CMAKE_PREFIX_PATH to keep them private. I expected them to build as submodules, but this seems to have failed for both projects. Not sure why. We are already using VCPkg on Windows as it is the recommended approach for gRPC, so this is not a problem. We have not containerized builds yet, so having private installations of dependencies is really important to us. Will confirm the results of testing. Thanks again! Kurt From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Tuesday, June 15, 2021 2:36 PM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) @BuildMan-Alpha <https://github.com/BuildMan-Alpha> Hi Kurt, Win32 fix is now merged in the main. Please pull it and try building for Win32. Re. CMAKE_PREFIX_PATH - this is interesting. We employ two (orthogonal) approaches: · nlohmann json from vcpkg installation: scripts that I shared above would use a local snapshot of vcpkg package management. And inside that one we install vcpkg install nlohmann-json:%ARCH%-windows , which is x64 by default and may optionally be set to x86. CMake should be able to find it. I do not see the issue with Could not find a package configuration file provided by "nlohmann_json". As long as I run the installation before the build. I think when you run these scripts, your build is also successful?... albeit with ninja, but ninja is a technicality - it could have been MSBuild. · nlohmann json from submodule: we also include a local snapshot of nlohmann json library, which you get in your workspace at third_party/nlohmann-json here <https://github.com/open-telemetry/opentelemetry-cpp/tree/main/third_party> , assuming you recursively cloned opentelemetry-cpp repository. Which appears like you did. There's one spot where we fallback to that submodule, assuming that your CMake installation (or vcpkg installation) did not provide the package. For example, piece of logic here - just uses the nlohmann json from submodule: https://github.com/open-telemetry/opentelemetry-cpp/blob/b073e8b785c72987b0b8a7623abcc5bd6bd9b208/ext/test/w3c_tracecontext_test/CMakeLists.txt#L7 Perhaps we should improve our top-level CMakeLists.txt to fallback to local submodules, if customer's system does not have the package already installed. Ultimately there is no right or wrong approach. What you are doing (providing your own dependency to CMake) - is also perfectly valid approach. Is this issue blocking you, would you consider adopting vcpkg as part of your build process on Windows (that'll give you some stable versions of GTest and nlohmann json)? Appears like you tested that this flow works okay. Or do you require specific versions of the packages? In that case what you are doing, providing your own dependencies - is the best thing to do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJTO4FN3KUM3M5O56YTTS6MQJANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJT5IRSTBM3YG7N25A3TS6MQJA5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGNORXVQ.gif>

[BuildMan-Alpha]

Hi Max, Win32 worked perfectly! Thank you! The submodule logic doesn’t seem to work on Windows for me. Ninja is installed, along with CMake 3.20. Build-CMake-Project-Windows : Error Invoking cmake to create the project files failed - level 1 Building with nostd types... CMake Error at C:/dev/vcpkg/scripts/buildsystems/vcpkg.cmake:263 (_find_package): By not providing "Findnlohmann_json.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "nlohmann_json", but CMake did not find one. Could not find a package configuration file provided by "nlohmann_json" with any of the following names: nlohmann_jsonConfig.cmake nlohmann_json-config.cmake Add the installation prefix of "nlohmann_json" to CMAKE_PREFIX_PATH or set "nlohmann_json_DIR" to a directory containing one of the above files. If "nlohmann_json" provides a separate development package or SDK, be sure it has been installed. Note: This is not a show-stopper, as I can build and install nlohmann_json as discussed previously using CMAKE_PREFIX_PATH. Just seems like it should work ”out-of-the-box” and I’m not sure what I may be doing wrong. Again, I’ve cloned recursively (most modules work). It works fine on Linux and WSL. Thanks again! Kurt From: Kurt Rayner ***@***.*** Sent: Tuesday, June 15, 2021 3:32 PM To: 'open-telemetry/opentelemetry-cpp'; 'open-telemetry/opentelemetry-cpp' Cc: 'BuildMan-Alpha'; 'Mention' Subject: RE: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) Hi Max, Great to hear Win32 is in the main branch! Running a test now. Ideally, I was hoping to just invoke CMake on an open source project and have all GitHub repositories it depends on built and install within the project. Setting up a build machine is tedious, and automating the installation really helps. As an old-school Visual Studio type, CMake is new to me, and I really like the concept and potential portability as we move to Windows/Linux/WSL builds. The gRPC team recommends using FetchContext_xxxx macros when including gRPC in a project and discourages installing gRPC globally as changing versions is “difficult”. Alas, the gRPC repository implementation itself has issues with FetchContent_xxxx macros for some dependencies, so I have had to learn a bit more than I expected about CMake… J CMAKE_PREFIX_PATH is something I stumbled on as a way to get at projects that are privately installed, and using it has gotten me past the CMake issues with OpenTelemetry (nlohmann_json and googletest). Yes, I had to clone, build and install both projects before OpenTelemetry and used CMAKE_PREFIX_PATH to keep them private. I expected them to build as submodules, but this seems to have failed for both projects. Not sure why. We are already using VCPkg on Windows as it is the recommended approach for gRPC, so this is not a problem. We have not containerized builds yet, so having private installations of dependencies is really important to us. Will confirm the results of testing. Thanks again! Kurt From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Tuesday, June 15, 2021 2:36 PM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) @BuildMan-Alpha <https://github.com/BuildMan-Alpha> Hi Kurt, Win32 fix is now merged in the main. Please pull it and try building for Win32. Re. CMAKE_PREFIX_PATH - this is interesting. We employ two (orthogonal) approaches: · nlohmann json from vcpkg installation: scripts that I shared above would use a local snapshot of vcpkg package management. And inside that one we install vcpkg install nlohmann-json:%ARCH%-windows , which is x64 by default and may optionally be set to x86. CMake should be able to find it. I do not see the issue with Could not find a package configuration file provided by "nlohmann_json". As long as I run the installation before the build. I think when you run these scripts, your build is also successful?... albeit with ninja, but ninja is a technicality - it could have been MSBuild. · nlohmann json from submodule: we also include a local snapshot of nlohmann json library, which you get in your workspace at third_party/nlohmann-json here <https://github.com/open-telemetry/opentelemetry-cpp/tree/main/third_party> , assuming you recursively cloned opentelemetry-cpp repository. Which appears like you did. There's one spot where we fallback to that submodule, assuming that your CMake installation (or vcpkg installation) did not provide the package. For example, piece of logic here - just uses the nlohmann json from submodule: https://github.com/open-telemetry/opentelemetry-cpp/blob/b073e8b785c72987b0b8a7623abcc5bd6bd9b208/ext/test/w3c_tracecontext_test/CMakeLists.txt#L7 Perhaps we should improve our top-level CMakeLists.txt to fallback to local submodules, if customer's system does not have the package already installed. Ultimately there is no right or wrong approach. What you are doing (providing your own dependency to CMake) - is also perfectly valid approach. Is this issue blocking you, would you consider adopting vcpkg as part of your build process on Windows (that'll give you some stable versions of GTest and nlohmann json)? Appears like you tested that this flow works okay. Or do you require specific versions of the packages? In that case what you are doing, providing your own dependencies - is the best thing to do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJTO4FN3KUM3M5O56YTTS6MQJANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJT5IRSTBM3YG7N25A3TS6MQJA5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGNORXVQ.gif>

[maxgolov]

I'll try to improve the handling of this, i.e. if outside CMake is not set up explicitly with the knowledge of GTest and nlohmann_json, then we should use the versions provided by our git submodules. Assigning to myself. But it'd be relatively low priority, since we already document how to build with vcpkg -provided dependencies.

[maxgolov]

It's a bit more tricky for GTest (which may not be required for the majority of build pipelines anyways, since it's only for the tests). And more straightforward for nlohmann/json.hpp . I sent out the fix to auto-discover the submodule-provided version of nlohmann/json.hpp in PR #865 .. at least partially alleviating your original concern.

[BuildMan-Alpha]

Hi Max, Having nlohmann_json work out of the box will definitely help folks get started. Note: I believe BUILD_TESTING is ON by default. If it were defaulted to OFF for 32-bit Windows, then perhaps a first-time CMAKE builder on Windows would not get errors… ??? Again, thank you! Best, Kurt From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Thursday, June 17, 2021 1:11 AM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) It's a bit more tricky for GTest (which may not be required for the majority of build pipelines anyways, since it's only for the tests). And more straightforward for nlohmann/json.hpp . I sent out the fix to auto-discover the submodule-provided version of it in #865 <#865> .. at least partially alleviating your original concern. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJWNQ5P37K5HIZOSZ6TTTF7URANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJRUZ56UMVV6ZITSSL3TTF7URA5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGNXUKQA.gif>

[maxgolov]

@BuildMan-Alpha - indeed, I agree we can improve the documentation piece for the GTest handling. Presently we manually build that in our integration loops. And the scripts I shared with you - these install vcpkg install gtest, essentially doing what you did. vcpkg uses common location for all CMake packages, whereas you are manually specifying the path to your own prebuilt GTest ( CMAKE_PREFIX_PATH pointing to your own build of it ). I merged the fix for nlohmann::json pakage. I'll consider a follow-up improvement for the GTest.

Perhaps we can also document the installation of GTest in either of these documents:
https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/building-with-vcpkg.md
https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/building-with-vs2019.md
?

For Unix OS - there's that write-up that explains how to install the GTest manually, for it to get auto-discovered by CMake:
https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/google-test.md#cmake

[BuildMan-Alpha]

Hi Max, Looks like there is a dependency for CMake in opentelemetry_exporter_etw that may need to be updated. Build-CMake-Project-Windows : Error Invoking cmake to create the project files failed - level 1 Using local nlohmann::json from submodule Building with nostd types... CMake Warning at examples/http/CMakeLists.txt:4 (message): Skipping http client/server example build: CURL not found CMake Error: install(EXPORT "opentelemetry-cpp-target" ...) includes target "opentelemetry_exporter_etw" which requires target "nlohmann_json" that is not in any export set. CMake Error in CMakeLists.txt: export called with target "opentelemetry_exporter_etw" which requires target "nlohmann_json" that is not in any export set. CMake Generate step failed. Build files cannot be regenerated correctly. Really appreciate all of your effort on this! Just having Win32 is a real help! Thanks again, Kurt From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Thursday, June 17, 2021 11:51 PM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) @BuildMan-Alpha <https://github.com/BuildMan-Alpha> - indeed, I agree we can improve the documentation piece for the GTest handling. Presently we manually build that in our integration loops. And the scripts I shared with you - these install vcpkg install gtest, essentially doing what you did. vcpkg uses common location for all CMake packages, whereas you are manually specifying the path to your own prebuilt GTest ( CMAKE_PREFIX_PATH pointing to your own build of it ). I merged the fix for nlohmann::json pakage. I'll consider a follow-up improvement for the GTest. Perhaps we can also document the installation of GTest in either of these documents: https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/building-with-vcpkg.md https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/building-with-vs2019.md ? For Unix OS - there's that write-up that explains how to install the GTest manually, for it to get auto-discovered by CMake: https://github.com/open-telemetry/opentelemetry-cpp/blob/main/docs/google-test.md#cmake — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJRJHRRCO5PNEWSEZ6DTTK7C3ANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJWRX37VY4FIXAW7JKLTTK7C3A5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGN5YUUI.gif>

[maxgolov]

@BuildMan-Alpha - apologies, I realized why it's breaking on Windows. As a workaround, you have two options:

• use vcpkg to manage your dependencies - vcpkg install nlohmann-json:x86-windows , then you may point your build to vcpkg via set VCPKG_ROOT="C:\vcpkg" - whatever directory where you have installed and built vcpkg... Then pass -DCMAKE_TOOLCHAIN_FILE="%VCPKG_ROOT}\scripts\buildsystems\vcpkg.cmake" parameter, to point CMake to vcpkg- installed dependency.

• or somehow otherwise build and install the JSON that we have available in the submodule.

I agree we need to fix this properly, since we do not have to force users to install their own instance of nlohmann::json. I tested this on Linux, but on Windows there's a special case with ETW exporter that needs fixing. I'll send out the fix for review promptly.

[maxgolov]

@BuildMan-Alpha - I realized there is a much nicer and easier workaround available for your build system. You do not need an immediate fix. You can add -DJSON_Install=ON option to your CMake command. That should solve the build issue for x86 / ETW exporter.

Short explanation: we do ship submodule of nlohmann::json library. But we were not installing it / not adding it to CMake cache. That caused an issue with ETW exporter, because it requires the nlohmann::json library to be installed / available in CMake list of packages. Other components, e.g. Linux builds - were fine as-is. Because Linux builds do not require the installation of json, only Windows ETW exporter build requires it.

Please try it by running CMake with your old arguments, plus -DJSON_Install=ON. Let me know if it works for you.

Meanwhile I'll submit a change to make this option to be ON by default. So you won't be needing to pass the JSON_Install parameter in the next release anymore. That'll make the overall onboarding experience a bit smoother.

[BuildMan-Alpha]

Hi Max, Works perfectly! So, currently, if I build OpenTelemetry-cpp with CMake from a clean clone of the repository and the following parameters (and have built and installed Ninja), the build works perfectly for both 64-bit and 32-bit builds on Windows.

…

-DCMAKE_POSITION_INDEPENDENT_CODE=ON -DWITH_PROMETHEUS=OFF -DBUILD_TESTING=OFF -DJSON_Install=ON Not sure if it would be more appropriate to make these default values (for now anyway until Prometheus is working) or to simply add something to the documentation for Windows builds. Always nicer if something “just works” the first time. Thank you again for all of the time you put into these issues! Really happy to be able to build and use Win32 builds on Windows. Best, Kurt From: 'Max Golovanov' via GithubAdmin ***@***.*** Sent: Friday, June 18, 2021 6:37 PM To: open-telemetry/opentelemetry-cpp Cc: BuildMan-Alpha; Mention Subject: Re: [open-telemetry/opentelemetry-cpp] Windows compile with CMake fails - Can't find googletest or nlohmann_json (#843) @BuildMan-Alpha <https://github.com/BuildMan-Alpha> - I realized there is a much nicer workaround available for your system. You do not need a fix. You can add -DJSON_Install=ON option to your CMake command, and that should solve the issue. Please try it. Meanwhile I'll submit a change to make this option ON by default, so you won't be needing to pass it in the next release. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#843 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOEBJSHAFOA7PU3HPSJHILTTPC7XANCNFSM46ON5CAQ> . <https://github.com/notifications/beacon/AAOEBJXQ735Y2HCYX7GS2ITTTPC7XA5CNFSM46ON5CA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGOCD4DQ.gif>