Проверяемая версия SDK: ydb-platform/ydb-cpp-sdk v3.21.0.
Окружение
- Windows x86-64
- Visual Studio Community 2022
17.14.38
- MSVC
19.44
- Clang
19.1.5, target x86_64-pc-windows-msvc
- CMake
3.31.6-msvc6
- Ninja из Visual Studio CMake Tools
- Conan
2.16.1
Ожидаемый результат
Возможность штатно собрать и подключить YDB C++ SDK в нативном Windows CMake-проекте либо использовать готовый официальный Windows binary package.
Обнаруженные проблемы
1. Нет готовых Windows-артефактов
GitHub release v3.21.0 содержит только Linux .deb-пакеты:
libydb-cpp-dev_3.21.0_amd64.deb;
yandex-googleapis-api-common-protos-1.0.0-Linux.deb;
- дополнительные
.deb для IAM и OpenTelemetry.
Windows .zip, .lib, .dll, NuGet package или другой готовый Windows SDK package отсутствует.
2. В документации отсутствует Windows dependency bundle
README описывает согласованный набор зависимостей и процедуру сборки для Ubuntu 24.04. Аналогичного списка готовых пакетов, package-manager manifest или воспроизводимого bootstrap-сценария для Windows нет.
Для сборки SDK потребовались:
- gRPC и protobuf;
- Abseil;
- OpenSSL;
- libidn и iconv;
- Brotli, zlib, zstd, lz4, Snappy, bzip2 и xxHash;
- double-conversion;
- RapidJSON;
- base64 и jwt-cpp;
protoc, Ragel и Yasm;
- git submodules SDK.
3. Точный рекомендованный gRPC отсутствует в Conan Center
README SDK v3.21.0 указывает gRPC 1.60.2. Такой версии в Conan Center не оказалось. В доступном списке после 1.54.3 следующей версией была 1.65.0.
Это не позволяет получить через Conan заявленный upstream набор версий без собственного recipe или другого способа сборки gRPC.
4. Различается нумерация protobuf
Указанный upstream protobuf release 25.0 соответствует линии Conan package protobuf/4.25.x, а не protobuf/5.25.x. Прямое использование номера release из README приводит к ошибке разрешения package:
ERROR: Package 'protobuf/5.25.3' not resolved:
Unable to find 'protobuf/5.25.3' in remotes.
5. Conan-профиль Clang для Windows не описывает MSVC runtime
При сборке с профилем:
os=Windows
arch=x86_64
compiler=clang
compiler.version=19
compiler.cppstd=20
compiler.runtime=dynamic
сборка Abseil завершилась ошибкой:
ConanException: Visual Studio Runtime version (v140-v144) not defined
Clang под Windows использует MSVC ABI/runtime, но стандартный Conan-профиль compiler=clang не содержит требуемого номера Visual Studio runtime.
Обходной профиль описывает ABI как MSVC и отдельно назначает clang-cl:
[settings]
os=Windows
arch=x86_64
build_type=Release
compiler=msvc
compiler.version=194
compiler.cppstd=20
compiler.runtime=dynamic
compiler.runtime_type=Release
[conf]
tools.cmake.cmaketoolchain:generator=Ninja
tools.build:compiler_executables={"c": "clang-cl", "cpp": "clang-cl"}
Однако это уже требует от пользователя самостоятельно знать и фиксировать ABI-модель, не описанную в инструкции SDK.
6. Для Windows/Clang отсутствует большинство готовых Conan binaries
После разрешения графа Conan планировал собирать из исходников практически все основные зависимости, включая:
- Abseil;
- protobuf;
- gRPC;
- OpenSSL;
- RE2;
- libidn и libiconv;
- библиотеки сжатия;
- double-conversion.
В результате получение SDK превращается в полную сборку большого dependency graph. До этапа компиляции самого YDB C++ SDK в этой попытке дойти не удалось.
Итог
CMake-код SDK содержит отдельные ветки для WIN32/AMD64, поэтому Windows формально учтён. Практическое использование осложнено отсутствием:
- официального Windows binary package;
- документированного Windows bootstrap;
- зафиксированного Windows dependency manifest;
- доступного через Conan точного рекомендованного набора версий.
Полезным исправлением был бы официальный Windows package либо проверяемый CI-сценарий с CMake preset и manifest для конкретного package manager.
Проверяемая версия SDK:
ydb-platform/ydb-cpp-sdk v3.21.0.Окружение
17.14.3819.4419.1.5, targetx86_64-pc-windows-msvc3.31.6-msvc62.16.1Ожидаемый результат
Возможность штатно собрать и подключить YDB C++ SDK в нативном Windows CMake-проекте либо использовать готовый официальный Windows binary package.
Обнаруженные проблемы
1. Нет готовых Windows-артефактов
GitHub release
v3.21.0содержит только Linux.deb-пакеты:libydb-cpp-dev_3.21.0_amd64.deb;yandex-googleapis-api-common-protos-1.0.0-Linux.deb;.debдля IAM и OpenTelemetry.Windows
.zip,.lib,.dll, NuGet package или другой готовый Windows SDK package отсутствует.2. В документации отсутствует Windows dependency bundle
README описывает согласованный набор зависимостей и процедуру сборки для Ubuntu 24.04. Аналогичного списка готовых пакетов, package-manager manifest или воспроизводимого bootstrap-сценария для Windows нет.
Для сборки SDK потребовались:
protoc, Ragel и Yasm;3. Точный рекомендованный gRPC отсутствует в Conan Center
README SDK v3.21.0 указывает gRPC
1.60.2. Такой версии в Conan Center не оказалось. В доступном списке после1.54.3следующей версией была1.65.0.Это не позволяет получить через Conan заявленный upstream набор версий без собственного recipe или другого способа сборки gRPC.
4. Различается нумерация protobuf
Указанный upstream protobuf release
25.0соответствует линии Conan packageprotobuf/4.25.x, а неprotobuf/5.25.x. Прямое использование номера release из README приводит к ошибке разрешения package:5. Conan-профиль Clang для Windows не описывает MSVC runtime
При сборке с профилем:
сборка Abseil завершилась ошибкой:
Clang под Windows использует MSVC ABI/runtime, но стандартный Conan-профиль
compiler=clangне содержит требуемого номера Visual Studio runtime.Обходной профиль описывает ABI как MSVC и отдельно назначает
clang-cl:Однако это уже требует от пользователя самостоятельно знать и фиксировать ABI-модель, не описанную в инструкции SDK.
6. Для Windows/Clang отсутствует большинство готовых Conan binaries
После разрешения графа Conan планировал собирать из исходников практически все основные зависимости, включая:
В результате получение SDK превращается в полную сборку большого dependency graph. До этапа компиляции самого YDB C++ SDK в этой попытке дойти не удалось.
Итог
CMake-код SDK содержит отдельные ветки для
WIN32/AMD64, поэтому Windows формально учтён. Практическое использование осложнено отсутствием:Полезным исправлением был бы официальный Windows package либо проверяемый CI-сценарий с CMake preset и manifest для конкретного package manager.