Новая итерация инструмента Conan для ОС Аврора

Содержание

Проблема управления зависимостями и пакетные менеджеры
Что такое Conan и где он применяется?
Установка Conan для разработки проектов
1. Как Conan устанавливался раньше
2. Новый способ установки Conan
Использование Conan-пакетов в ОС Аврора
Документация
Основные ссылки

Проблема управления зависимостями и пакетные менеджеры

В отличие от современных языков программирования, таких как Rust, Go или Python, в стандартном C++ отсутствует встроенный пакетный менеджер. Это фундаментальная архитектурная проблема языка, которая вынуждает разработчиков тратить часы не на написание кода, а на решение проблем подключения библиотек.

Ситуация усугубляется спецификой разработки под ОС Аврора:

Кросс-компиляция. Разработка проектов ведётся не только под архитектуру x86_64, но и aarch64 и armv7hl. Для каждой архитектуры требуется свой тулчейн и набор флагов компилятора.
Тяжеловесные библиотеки. Такие зависимости, как LibreOffice Core или WebRTC, требуют нескольких часов сборки даже на мощном оборудовании. Необходимость их сборки под каждую целевую архитектуру приводит к значительным временным затратам.
Ограничения SDK Build Tools. Окружение SDK BT представляет собой изолированную неизменяемую среду, которая не позволяет устанавливать зависимости напрямую через системные пакетные менеджеры.

Данные ограничения приводят к необходимости использовать внешний инструмент, который:

работает поверх SDK, то есть соотносится с политикой неизменяемости SDK Build Tools;
поддерживает кросс-компиляцию под несколько архитектур;
обеспечивает кэширование библиотек для ускорения сборки;
позволяет разворачивать приватный репозиторий для внутренних библиотек.

Для решения выявленных проблем был проведен сравнительный анализ доступных механизмов управления зависимостями: Conan, vcpkg и встроенных средств CMake (CPM.cmake, FetchContent).

Тип решения: Conan и vcpkg представляют собой выделенные пакетные менеджеры с собственными репозиториями, в то время как встроенные средства CMake реализуют механизм загрузки исходных кодов непосредственно в процессе конфигурации и сборки.
Бинарное кэширование: Наличие кэширования скомпилированных артефактов в Conan и vcpkg критически важно для тяжеловесных библиотек. Инструмент FetchContent пересобирает зависимости при каждой новой проверке кода, что ведет к нерациональному расходу вычислительных ресурсов.
Управление версиями: Использование механизмов фиксации версий (lock-файлов) в Conan гарантирует идентичность набора зависимостей для всех участников разработки и конвейеров CI/CD.
Поддержка приватных репозиториев: Развертывание собственных серверов с артефактами доступно для пакетных менеджеров Conan и vcpkg, но недоступно для FetchContent.

По совокупности критериев, учитывая необходимость кросс-компиляции под изолированные окружения ОС Аврора, поддержку нескольких архитектур и работу с объемными зависимостями, инструмент Conan был выбран в качестве индустриального стандарта для разработки.

Что такое Conan и где он применяется?

Conan — это децентрализованный, кроссплатформенный и открытый менеджер пакетов для языков C и C++. Он решает ключевую проблему разработки на C/C++ — управление внешними библиотеками и их зависимостями, автоматизируя процесс их загрузки, сборки и интеграции в проект.

Децентрализованная архитектура инструмента позволяет использовать как публичные репозитории Conan-пакетов, так и разворачивать приватные серверы с собственными пакетами.

Кроссплатформенность Conan обеспечивает работу на Windows, Linux и macOS, а также поддержку популярных компиляторов: GCC, Clang, MSVC. Инструмент успешно справляется с кросс-компиляцией под aarch64 и armv7hl.

Открытый исходный код предоставляет возможность доработки менеджера под специфические нужды и гарантирует независимость от внешних ограничений доступа.

Главная задача, которую решает данный инструмент, — это автоматизация процесса работы с внешними зависимостями. Он берет на себя загрузку библиотек и их интеграцию в собираемый проект.

Conan представляет собой пакетный менеджер, восполняющий исторический пробел в экосистеме C++. В отличие от аналогов в Python или JavaScript, он учитывает архитектуру, компилятор, версию операционной системы и ABI-совместимость.

Установка Conan для разработки проектов

Интеграция Conan в процесс разработки проектов эволюционирует параллельно с развитием инструментов ОС Аврора. В связи с планомерным переходом на новые способы поставки среды сборки, подходы к работе с пакетным менеджером также оптимизируются и совершенствуются.

Недостатки старого способа установки Conan в проект

Загрузка отдельных RPM-пакетов для Conan из специального репозитория или самостоятельная сборка из исходного кода.
Раздельная установка для каждого таргета, что увеличивало вероятность ошибок из-за многократного повторения одних и тех же действий.
Значительные временные затраты на сборку из исходников или установку RPM-пакетов в виртуальную машину или chroot-окружение.

Новый способ установки Conan

Переход ОС Аврора на новую контейнизированную среду Build Tools потребовал изменения способа поставки пакетного менеджера Conan. Прежний подход стал неактуален по двум причинам:

Файловая система среды Build Tools доступна только для чтения. Новая среда сборки поставляется как неизменяемый Docker-контейнер, поэтому установка сторонних RPM-пакетов невозможна.
Отсутствует системный интерпретатор Python, необходимый для работы Conan.

Ответом на ограничения среды Build Tools стал новый способ поставки Conan в виде самодостаточного дистрибутива.

Вместо RPM-пакета инструмент теперь поставляется в виде единого архива, содержащего:

собственный интерпретатор Python;
исполняемые файлы менеджера пакетов Conan;
набор профилей кросс-компиляции для целевых архитектур (aarch64, armv7hl);
скрипты-обёртки для автоматизации рутинных задач.

Для упрощения установки и работы с новым дистрибутивом создан скрипт инициализации load-conan.sh.

В его задачи входит:

Определение типа среды сборки (MB2, BT или PSDK).
Вычисление пути расположения дистрибутива Conan.
Проверка наличия дистрибутива (при отсутствии выполняется его загрузка и распаковка).

Важным нововведением является механизм хранения артефактов. Дистрибутив менеджера пакетов, а также все загруженные зависимости кэшируются в централизованной директории на рабочей станции разработчика: ~/Aurora Projects/.cache/AuroraTools/. Использование единого хранилища позволяет многократно переиспользовать скачанные зависимости в различных проектах без повторной загрузки из сети.

Кроме того, данный подход значительно упрощает процесс очистки окружения. Для полного удаления менеджера Conan и всех загруженных бинарных библиотек достаточно удалить директорию ~/.cache/ из корня рабочего пространства. Это действие не требует взаимодействия с утилитами sb2 или выполнения команд по удалению пакетов (таких как zypper remove). Данный метод безопасен, быстр и оптимально подходит для работы в условиях изолированной среды Build Tools.

Таким образом, новый подход решает две важные задачи: делает пакетный менеджер доступным для разработки в новой среде Build Tools и избавляет разработчиков от необходимости ручной установки и настройки Conan.

Использование Conan-пакетов в ОС Аврора

Собственный сервер Conan-пакетов

Существуют три ключевых фактора, обосновывающих необходимость использования собственного сервера Conan-пакетов:

Целевые архитектуры. Публичный Conan Center ориентирован в первую очередь на массовые платформы: x86_64 под Windows и популярные дистрибутивы Linux, тогда как разработка под ОС Аврора ведётся под aarch64 и armv7hl.
Внутренние библиотеки. Разработка специфичных библиотек под ОС Аврора (например, amberpdf для работы с PDF-документами или картографический фреймворк mfw), которые отсутствуют на публичных серверах.
Хранение тяжеловесных библиотек. Хранение скомпилированных версий таких библиотек, как LibreOffice Core или WebRTC, на отдельном сервере избавляет от необходимости их локальной компиляции.

Для хранения артефактов выбран JFrog Artifactory — универсальный репозиторий, поддерживающий более 40 форматов пакетов и обеспечивающий единый источник истины для всех команд и CI/CD-конвейеров.

Подробнее про доступные пакеты Conan для ОС Аврора и сборку дистрибутива менеджера пакетов можно узнать по следующим ссылкам:

Aurora Conan — хранилище рецептов.
Conan Client — инструменты для сборки дистрибутива Conan для SDK.
Conan Client Rpm — готовые RPM с утилитой Conan (результат сборки Conan Client).

Что такое рецепт Conan?

Рецепт Conan — это файл с именем conanfile.py, написанный на Python, который служит главной инструкцией для менеджера пакетов. Он полностью описывает процессы получения, сборки, упаковки и использования определённой библиотеки или приложения.

Структура рецепта:

Метаданные: имя и версия пакета, а также опционально лицензия, автор и другая информация.
Бинарная конфигурация: настройки (settings) и опции (options). Settings — это глобальные параметры (ОС, компилятор, архитектура), а options — специфичные для пакета (например, сборка библиотеки как статической или динамической).
Методы-инструкции: методы, вызываемые Conan в процессе работы:
- source(): определяет источник загрузки исходного кода (Git, архив и т.д.).
- generate(): подготавливает окружение для сборки (например, генерация файлов для CMake).
- build(): выполняет непосредственную сборку библиотеки из исходных кодов.
- package(): осуществляет копирование готовых файлов (заголовочные файлы, библиотеки) в финальную структуру пакета.
- package_info(): передает потребителям пакета информацию о библиотеках для линковки и расположении заголовочных файлов.

Рецепты применяются в двух основных сценариях:

Создание собственных пакетов. Для распространения библиотеки внутри команды разрабатывается соответствующий рецепт. Команда conan new позволяет сгенерировать шаблон такого рецепта. Далее с помощью команды conan create осуществляется сборка и упаковка библиотеки. Дополнительная информация о командах Conan доступна на сайте docs.conan.io.
Потребление пакетов. При использовании сторонних библиотек они описываются в conanfile.py проекта. В этом случае рецепт выступает в роли списка зависимостей, а его методы (например, build()) могут использоваться для сборки самого приложения.

В качестве примера приведён файл conanfile.py для сборки пакета под ОС Аврора:

from conan import ConanFile
from conan.tools.files import get, copy, patch, rmdir
from conan.tools.cmake import CMake, CMakeToolchain, CMakeDeps, cmake_layout

import os

class AmberPDFConan(ConanFile):
    name = "amberpdf"
    package_type = "library"
    user = "aurora"

    license = "BSD-3-Clause"
    author = "Developer Name <app.developer@mail.address>"
    url = "https://hub.mos.ru/auroraos/libraries/amberpdf"
    description = "PDFium wrapper library for Qt."

    settings = "os", "arch", "compiler", "build_type"
    options = {
        "shared": [True, False],
        "fPIC": [True, False],
    }
    default_options = {
        "shared": True,
        "fPIC": True,
    }
    exports = ["CMakeLists.txt", "patches/*"]

    def layout(self):
        cmake_layout(self)

    def build_requirements(self):
        self.tool_requires("ninja/[>=1.10.2]@aurora")

    def source(self):
        get(self, **self.conan_data["sources"][self.version], strip_root=True)

    def generate(self):
        deps = CMakeDeps(self)

Подключение Conan

Для подключения Conan к проекту необходимо выполнить ряд действий.

Первый шаг — создание конфигурационного файла. В корне проекта создается файл conanfile.py с описанием требуемых пакетов. В атрибуте requires перечисляются все необходимые зависимости (например, ffmpeg/6.1.1@aurora).

Второй шаг — настройка RPM-спецификации (файла .spec):

В начало файла добавляются следующие директивы для изоляции загружаемых зависимостей от других проектов:

%define __provides_exclude_from
%define __requires_exclude

Добавляется директива для загрузки менеджера Conan (запускает скрипт, который скачивает дистрибутив и загружает команды по работе с ним):

%{expand:%(bash %{_sourcedir}/load-conan.sh)}

В секции %build обычный вызов CMake заменяется на макросы Conan:

%build
%conan_install
%conan_cmake

В секции %install добавляется макрос для копирования всех необходимых библиотек в RPM-пакет:

%install
%conan_deploy_libraries

Третий шаг — настройка CMakeLists.txt. Пакеты подключаются стандартными средствами CMake через pkg-config:

Добавляется команда поиска pkg-config:

find_package(PkgConfig REQUIRED)

Выполняется поиск для каждого пакета (например, для ffmpeg):

pkg_check_modules(FFMPEG REQUIRED IMPORTED_TARGET ffmpeg)

Четвертый шаг — настройка путей для работы приложения на устройстве. В ОС Аврора библиотеки приложения располагаются в /usr/share/<имя_приложения>/lib. Для корректного поиска библиотек исполняемым файлом настраивается rpath:

В .spec-файл добавляется:

%define _cmake_skip_rpath %{nil}

В CMakeLists.txt добавляется:

set(CMAKE_SKIP_RPATH FALSE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/share/${PROJECT_NAME}/lib")

После выполнения указанных шагов проект настроен и готов к работе с Conan.

Ограничения при использовании Conan

Существуют три особенности, накладывающие ограничения на работу с пакетным менеджером Conan:

Поддержка только CMake-приложений. Conan используется как генератор для CMake. Он формирует специальный тулчейн-файл и передает все необходимые пути к библиотекам, флаги компилятора и определения.
Распространение пакетов преимущественно в бинарном виде. На центральном сервере Conan размещаются заранее скомпилированные бинарные артефакты под все целевые архитектуры (x86_64, aarch64, armv7hl) и версии библиотек. При проведении локальной сборки сформированный пакет сохраняется исключительно во внутреннем кэше Conan на рабочей станции, без загрузки на удаленный сервер. Прямая публикация бинарных файлов и рецептов внешними разработчиками не предусмотрена; добавление новых пакетов на центральный сервер осуществляется путем обращения в службу поддержки (dev-support). Использование готовых бинарных артефактов позволяет существенно ускорить сборку проектов, гарантировать единообразие поведения программного обеспечения и предотвратить проблемы с совместимостью.
Ограничения инструмента копирования зависимостей. Настоятельно рекомендуется использовать инструмент pkg-config. Механизм автоматического копирования зависимостей в ОС Аврора опирается на файлы .pc. В противном случае разработчику придется вручную прописывать пути до всех .so и include файлов.

Просмотр доступных пакетов Conan

Хранилище артефактов Conan доступно по адресу: https://conan.omp.ru. В разделе Artifactory → Artifacts → public → aurora располагаются бинарные файлы всех хранящихся на сервере библиотек.

На данный момент на сервере размещено 10 419 артефактов из 109 пакетов.

Добавление собственных пакетов Conan

При разработке проектов под ОС Аврора может потребоваться добавление собственных пакетов. Этот процесс состоит из следующих этапов:

Создание рецепта для новой библиотеки с описанием источников исходного кода, инструкций по сборке под различные архитектуры и списка зависимостей.
Добавление рецепта в центральный репозиторий AuroraConan.
Прохождение код-ревью для обеспечения качества и корректности сборки.
Запуск процесса сборки и публикация готовых бинарных артефактов на корпоративном сервере Conan.

Подробные инструкции по сборке пакетов с использованием скриптов из репозитория AuroraConan представлены в официальной документации. Сборка поддерживается как в Аврора SDK, так и в Platform SDK.

Примеры, где уже встроен Conan

Примеры использования Conan в приложениях представлены на ресурсе https://hub.mos.ru/auroraos:

Документация

Официальная документация доступна на портале разработчиков: https://developer.auroraos.ru/doc/extended/conan.