azure-sdk-for-cpp/CMakeLists.txt

176 строки
6.7 KiB
CMake
Исходник Постоянная ссылка Обычный вид История

# Copyright (c) Microsoft Corporation.
# Licensed under the MIT License.
2020-02-20 23:10:01 +03:00
# cspell: words fsanitize
cmake_minimum_required (VERSION 3.13)
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake-modules")
2020-02-20 23:10:01 +03:00
2020-12-11 22:53:37 +03:00
# Variable to indicate whether the entire SDK is being built, as opposed to an individual library.
set(AZ_ALL_LIBRARIES ON)
# Compile Options
include(FolderList)
SetGlobalOptions()
if(FETCH_SOURCE_DEPS)
message(FATAL_ERROR, "FETCH_SOURCE_DEPS flag not for global use, instead use when building individual components")
return()
endif()
2020-02-20 23:10:01 +03:00
include(AzureTransportAdapters)
include(AzureVcpkg)
2022-01-20 21:09:06 +03:00
include(AzureBuildTargetForCI)
az_vcpkg_integrate()
2020-02-20 23:10:01 +03:00
# Project definition
project(azure-sdk LANGUAGES CXX C)
set(CMAKE_CXX_STANDARD 14)
2020-02-20 23:10:01 +03:00
set(CMAKE_CXX_STANDARD_REQUIRED True)
# Enable a build configuration to disable features when building for Windows Store.
message(STATUS "CMAKE_SYSTEM_NAME=" ${CMAKE_SYSTEM_NAME} ";")
message(STATUS "VCPKG_TARGET_TRIPLET=" ${VCPKG_TARGET_TRIPLET} ";")
# In the CI pipeline, for <reasons>, CMAKE_SYSTEM_NAME is set to "Windows" even when building for Windows Store.
# use the CMAKE triplet to detect the windows store build.
if ((${VCPKG_TARGET_TRIPLET} MATCHES ".*-uwp"))
set(BUILD_WINDOWS_UWP True)
message(STATUS "Building for Windows Store, CMAKE_SYSTEM_NAME=" ${CMAKE_SYSTEM_NAME})
endif()
# For MSVC, ensure that the compiler is operating in strict compliance mode.
if (MSVC)
# See also: https://learn.microsoft.com/cpp/build/reference/permissive-standards-conformance
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /permissive-")
endif()
if(MSVC_USE_STATIC_CRT AND MSVC)
# 1. More about static/shared CRT:
# https://docs.microsoft.com/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-160
#
# 2. MSVC_USE_STATIC_CRT build flag approach is used/inspired by libcurl
# (https://github.com/curl/curl/blob/master/CMakeLists.txt) and some other projects.
#
# 3. GTest would emit the following warning:
# warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
# AddGoogleTest.cmake uses gtest_force_shared_crt
# (see https://github.com/google/googletest/blob/master/googletest/README.md),
# which respects linker settings that we set below, and our settings below are all in sync.
#
# 4. Sometimes, the following approach is recommended instead:
# +-----------------------------------------------------------------------------------+
# | # Use the static runtime libraries when building statically |
# | # for consistency with the vcpkg arch-windows-static triplets: |
# | cmake_policy(SET CMP0091 NEW) |
# | # see https://cmake.org/cmake/help/v3.15/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html |
# | if (NOT DEFINED CMAKE_MSVC_RUNTIME_LIBRARY) |
# | set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>") |
# | endif() |
# +-----------------------------------------------------------------------------------+
# However, it only works when cmake installed is 3.15+;
# we have to require a minimum of 3.13.
#
# 5. We "replace with empty string" (i.e. remove) first, then add, so that '/MT'
# will be present (and present once) even if '/MD' was not.
message(STATUS "Configuring Static Runtime Library.")
if(${CMAKE_CXX_FLAGS} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MT")
endif()
if(${CMAKE_CXX_FLAGS_RELEASE} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")
endif()
if(${CMAKE_CXX_FLAGS_RELWITHDEBINFO} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO} /MT")
endif()
if(${CMAKE_CXX_FLAGS_MINSIZEREL} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_CXX_FLAGS_MINSIZEREL "${CMAKE_CXX_FLAGS_MINSIZEREL}")
set(CMAKE_CXX_FLAGS_MINSIZEREL "${CMAKE_CXX_FLAGS_MINSIZEREL} /MT")
endif()
if(${CMAKE_CXX_FLAGS_DEBUG} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MDd" "" CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
endif()
# Now make the same adjustments for .C files as was done for .CPP files.
if(${CMAKE_C_FLAGS} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /MT")
endif()
if(${CMAKE_C_FLAGS_RELEASE} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}")
set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT")
endif()
if(${CMAKE_C_FLAGS_RELWITHDEBINFO} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO}")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT")
endif()
if(${CMAKE_C_FLAGS_MINSIZEREL} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MD" "" CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL}")
set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT")
endif()
if(${CMAKE_C_FLAGS_DEBUG} MATCHES ".*/MD.*")
string(REGEX REPLACE "/MDd" "" CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG}")
set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd")
endif()
endif()
# If the cmake presets enable Address Sanitizer, enable it for the project.
if (ENABLE_ADDRESS_SANITIZER)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address")
endif()
if(BUILD_TESTING)
include(AddGoogleTest)
enable_testing ()
endif()
# compiler warning flags globally
include(AzureGlobalCompileOptions)
# Add create_map_file function
include(CreateMapFile)
# Documentation automation function
include(AzureDoxygen)
# Functions for library versions
include(AzureVersion)
Encapsulate getenv(), and make it work on UWP (#3275) It all started with UWP. The [docs](https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-170) say: "`Environment variables are not available to UWP apps.`". And it truly won't work, I tried: linker error, the function is simply not present. So, for a year or so, we were `ifdef`ing everything enivoronment-related: console logger, environment credential, managed identity credential. And then just recently we wanted to enable our CI for UWP, including tests and samples. And it required to do more ifdefs (in vcpkg, we don't build samples or tests, so that problem did not exist). It just became more messy. Especially in samples - you can see how we would disable warning with `#pragma warning(disable : 4996)` or defining `_CRT_SECURE_NO_WARNINGS` already, but now came UWP, so we would have to add comment that `getenv()` is not available and make the sample compilation to either fail with clear message, or throw an exception. Plus we would have to detect that we are being compiled on UWP, which also adds visual clutter for reader. You can see how such an irrelevant (for a sample) thing as `getenv` was consuming more and more lines of sample code and reader's attention. But then! I read docs on more APIs for UWP. And I noticed that on .NET you can read environment variables. So I went and checked Win32 API docs for [GetEnvironmentVariable()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenvironmentvariable) - it says: "`Minimum supported client: ... UWP apps`". **GetEnvironmentVariable() works on UWP!** And so does `SetEnvironmentVariable()` (our tests use it, which means we can make all of them work and execute for UWP). That's good news, but now it would probably be more code: it usually takes more lines to invoke WinAPI, it is no more an one-liner to call `getenv()/setenv()`. So, I encapsulated that into `Azure::Core::_internal::Environment::GetVariable()` and `SetVariable()`. You can see how much less ifdefs is in our code now. Not to mention it works on UWP! Per team request, that API is SDK-internal. Samples use their own mini-helper project, `get-env-helper` that makes is so that `getenv()` works naturally on Linux and macOS, compiles without warnings and works on Win32, and compiles and works on UWP (using `GetEnvironmentStringsA()`) If it was for me, I would just make `Azure::Core::Environment::GetVariable()` public and simplify even further, I think it would be beneficial for sample readers (you can see that extra `get-env-helper` stuff adds just a little more visual clutter, compared to nothing). But I can see reasons against that, why team did not want to do it.
2022-01-29 11:22:33 +03:00
if(BUILD_SAMPLES)
add_subdirectory(samples/helpers/get-env)
add_subdirectory(samples/helpers/service)
Encapsulate getenv(), and make it work on UWP (#3275) It all started with UWP. The [docs](https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-170) say: "`Environment variables are not available to UWP apps.`". And it truly won't work, I tried: linker error, the function is simply not present. So, for a year or so, we were `ifdef`ing everything enivoronment-related: console logger, environment credential, managed identity credential. And then just recently we wanted to enable our CI for UWP, including tests and samples. And it required to do more ifdefs (in vcpkg, we don't build samples or tests, so that problem did not exist). It just became more messy. Especially in samples - you can see how we would disable warning with `#pragma warning(disable : 4996)` or defining `_CRT_SECURE_NO_WARNINGS` already, but now came UWP, so we would have to add comment that `getenv()` is not available and make the sample compilation to either fail with clear message, or throw an exception. Plus we would have to detect that we are being compiled on UWP, which also adds visual clutter for reader. You can see how such an irrelevant (for a sample) thing as `getenv` was consuming more and more lines of sample code and reader's attention. But then! I read docs on more APIs for UWP. And I noticed that on .NET you can read environment variables. So I went and checked Win32 API docs for [GetEnvironmentVariable()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenvironmentvariable) - it says: "`Minimum supported client: ... UWP apps`". **GetEnvironmentVariable() works on UWP!** And so does `SetEnvironmentVariable()` (our tests use it, which means we can make all of them work and execute for UWP). That's good news, but now it would probably be more code: it usually takes more lines to invoke WinAPI, it is no more an one-liner to call `getenv()/setenv()`. So, I encapsulated that into `Azure::Core::_internal::Environment::GetVariable()` and `SetVariable()`. You can see how much less ifdefs is in our code now. Not to mention it works on UWP! Per team request, that API is SDK-internal. Samples use their own mini-helper project, `get-env-helper` that makes is so that `getenv()` works naturally on Linux and macOS, compiles without warnings and works on Win32, and compiles and works on UWP (using `GetEnvironmentStringsA()`) If it was for me, I would just make `Azure::Core::Environment::GetVariable()` public and simplify even further, I think it would be beneficial for sample readers (you can see that extra `get-env-helper` stuff adds just a little more visual clutter, compared to nothing). But I can see reasons against that, why team did not want to do it.
2022-01-29 11:22:33 +03:00
endif()
# sub-projects
add_subdirectory(sdk/core)
add_subdirectory(sdk/appconfiguration)
add_subdirectory(sdk/attestation)
# AMQP doesn't work for UWP yet, and eventhubs depends on AMQP, so we cannot include eventhubs on UWP.
if (NOT BUILD_WINDOWS_UWP)
add_subdirectory(sdk/eventhubs)
endif()
add_subdirectory(sdk/identity)
add_subdirectory(sdk/keyvault)
add_subdirectory(sdk/storage)
add_subdirectory(sdk/template)
Storage tables implementation (#5137) * dss * first pass at a client and tests * constructors work * working request, need to fix the response parsing * basic tests working for service client * refactored the constructors * testproxy and tests * format file * got client and one API working * list working * all apis recorded * new assets.json * assets.json regen * format json * adding word to cspell * fix build issues * fix one more break * typo * clangs * one more issue * more fixezez * regen recordings * try again * clangs * clangs again * new assets * new test proxy * regen tests based on new merge * hmmm * restore * add debug env for test proxy * resync cmake presets from main * gor get and set working * get stats * table client and create * delete * get/set acls * list tables * some cleanup * Create /update/merge/delete * upsert * query entities * generated tests * clangs * some fixes * some more errors * cspells * got transaction API working * transactions working , need to parse response * get data out of the response * clangs * batch1 * regen tests * part 2 * batch3 * batch4 * clangs * regen tests * regen tests * try again * live only * added some more tests for the transaction body * small refactor for tests * oops * some oter update * darn includes * sddfsd * erorr fix * key clients * sas * small cleanup * All tests passing * test recordings * clangs * missing ENV for test * attempt1 * retry * couple recordings * regen some tests * clangs * again * again * comments * comments * headers and footers * some cleanjup * Move folders step1 * revert assets and test resources in storage * revert to main * cspell * readme * comments * revert ci.yml * liveonly test * clangs * camke * ci2 * try again * fdssfs * fdsfsd * some cleanup * dasda * dsdsds * asda * assets * comments * a few more bits and pieces * some other updates for cspell * typo * more docs * spell * another doc error * clangs docs * docs * test cov * dasdas * hg * stress test * cspell * Update sdk/storage/azure-storage-common/test/ut/CMakeLists.txt Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/storage/azure-storage-common/test/ut/shared_key_policy_lite_test.cpp Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/CHANGELOG.md Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/CMakeLists.txt Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/test/stress/scenarios-matrix.yaml Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/test/stress/Dockerfile Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * PR comments * respurces cleanup * cleanup 2 * respurce fix * revddrt * weqq * oops * try again * Update sdk/tables/azure-data-tables/vcpkg/vcpkg.json Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * try * test fix * samples * readmes * readmes * readmes * api view settings * qualify friends * try * moving usings * refactor for API View tool * some more * clangs * Update sdk/tables/README.md Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/core/azure-core/inc/azure/core/http/http.hpp Co-authored-by: Ahson Khan <ahkha@microsoft.com> * Update sdk/core/azure-core/src/http/transport_policy.cpp Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/inc/azure/data/tables/rest_client.hpp Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/CHANGELOG.md Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/test/ut/CMakeLists.txt Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * Update sdk/tables/azure-data-tables/src/rest_client.cpp Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * some comments * comments * comments part N * clang * try now * clang * comments * update file names * update test to check for the final signature * ccc * rename shared key policy lite * cleanup some includes * add a couple more tests * small update * clang * increase test limits * xml transition * service_version_policy * shared creds and key policy lite * switch to secondary policy * code done * remove last storage vestiges * put back some code * readme/changelog * Update sdk/tables/azure-data-tables/src/serializers.cpp Co-authored-by: Rick Winter <rick.winter@microsoft.com> * Add the shared key policy for Larry * Larry comments * curlybracify the initializers * Update sdk/core/azure-core-xml/inc/azure/core/xml/dll_import_export.hpp Co-authored-by: Rick Winter <rick.winter@microsoft.com> * Update sdk/core/azure-core-xml/vcpkg.json Co-authored-by: Rick Winter <rick.winter@microsoft.com> * Update sdk/tables/azure-data-tables/inc/azure/data/tables.hpp Co-authored-by: Rick Winter <rick.winter@microsoft.com> * Rick's comments one more namespace change for serializers * whiteline * typo * oops * includes and clangs * cleanup * jhfjdhjfd * hjkjdhf * daas * Anton's comments * clang * revert some changes * fdss * Update sdk/core/azure-core-xml/CHANGELOG.md Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> * everything works * clangs and vcpkg test * test remove azure-core-xml * vcpkg json * remove the code * merge main * saa * wqw * last comments * clang --------- Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com> Co-authored-by: Ahson Khan <ahkha@microsoft.com> Co-authored-by: Rick Winter <rick.winter@microsoft.com>
2024-01-12 22:04:43 +03:00
add_subdirectory(sdk/tables)
Encapsulate getenv(), and make it work on UWP (#3275) It all started with UWP. The [docs](https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-170) say: "`Environment variables are not available to UWP apps.`". And it truly won't work, I tried: linker error, the function is simply not present. So, for a year or so, we were `ifdef`ing everything enivoronment-related: console logger, environment credential, managed identity credential. And then just recently we wanted to enable our CI for UWP, including tests and samples. And it required to do more ifdefs (in vcpkg, we don't build samples or tests, so that problem did not exist). It just became more messy. Especially in samples - you can see how we would disable warning with `#pragma warning(disable : 4996)` or defining `_CRT_SECURE_NO_WARNINGS` already, but now came UWP, so we would have to add comment that `getenv()` is not available and make the sample compilation to either fail with clear message, or throw an exception. Plus we would have to detect that we are being compiled on UWP, which also adds visual clutter for reader. You can see how such an irrelevant (for a sample) thing as `getenv` was consuming more and more lines of sample code and reader's attention. But then! I read docs on more APIs for UWP. And I noticed that on .NET you can read environment variables. So I went and checked Win32 API docs for [GetEnvironmentVariable()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenvironmentvariable) - it says: "`Minimum supported client: ... UWP apps`". **GetEnvironmentVariable() works on UWP!** And so does `SetEnvironmentVariable()` (our tests use it, which means we can make all of them work and execute for UWP). That's good news, but now it would probably be more code: it usually takes more lines to invoke WinAPI, it is no more an one-liner to call `getenv()/setenv()`. So, I encapsulated that into `Azure::Core::_internal::Environment::GetVariable()` and `SetVariable()`. You can see how much less ifdefs is in our code now. Not to mention it works on UWP! Per team request, that API is SDK-internal. Samples use their own mini-helper project, `get-env-helper` that makes is so that `getenv()` works naturally on Linux and macOS, compiles without warnings and works on Win32, and compiles and works on UWP (using `GetEnvironmentStringsA()`) If it was for me, I would just make `Azure::Core::Environment::GetVariable()` public and simplify even further, I think it would be beneficial for sample readers (you can see that extra `get-env-helper` stuff adds just a little more visual clutter, compared to nothing). But I can see reasons against that, why team did not want to do it.
2022-01-29 11:22:33 +03:00
if(BUILD_SAMPLES)
add_subdirectory(samples/integration/vcpkg-all-smoke)
Encapsulate getenv(), and make it work on UWP (#3275) It all started with UWP. The [docs](https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-170) say: "`Environment variables are not available to UWP apps.`". And it truly won't work, I tried: linker error, the function is simply not present. So, for a year or so, we were `ifdef`ing everything enivoronment-related: console logger, environment credential, managed identity credential. And then just recently we wanted to enable our CI for UWP, including tests and samples. And it required to do more ifdefs (in vcpkg, we don't build samples or tests, so that problem did not exist). It just became more messy. Especially in samples - you can see how we would disable warning with `#pragma warning(disable : 4996)` or defining `_CRT_SECURE_NO_WARNINGS` already, but now came UWP, so we would have to add comment that `getenv()` is not available and make the sample compilation to either fail with clear message, or throw an exception. Plus we would have to detect that we are being compiled on UWP, which also adds visual clutter for reader. You can see how such an irrelevant (for a sample) thing as `getenv` was consuming more and more lines of sample code and reader's attention. But then! I read docs on more APIs for UWP. And I noticed that on .NET you can read environment variables. So I went and checked Win32 API docs for [GetEnvironmentVariable()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenvironmentvariable) - it says: "`Minimum supported client: ... UWP apps`". **GetEnvironmentVariable() works on UWP!** And so does `SetEnvironmentVariable()` (our tests use it, which means we can make all of them work and execute for UWP). That's good news, but now it would probably be more code: it usually takes more lines to invoke WinAPI, it is no more an one-liner to call `getenv()/setenv()`. So, I encapsulated that into `Azure::Core::_internal::Environment::GetVariable()` and `SetVariable()`. You can see how much less ifdefs is in our code now. Not to mention it works on UWP! Per team request, that API is SDK-internal. Samples use their own mini-helper project, `get-env-helper` that makes is so that `getenv()` works naturally on Linux and macOS, compiles without warnings and works on Win32, and compiles and works on UWP (using `GetEnvironmentStringsA()`) If it was for me, I would just make `Azure::Core::Environment::GetVariable()` public and simplify even further, I think it would be beneficial for sample readers (you can see that extra `get-env-helper` stuff adds just a little more visual clutter, compared to nothing). But I can see reasons against that, why team did not want to do it.
2022-01-29 11:22:33 +03:00
endif()