Одной из наиболее признанных и хорошо-известных проблем С++ является проблема доставки внешних зависимостей. В докладе очерчиваются проблемы доставки зависимостей, рассматриваются распространенные пути решения и их связи с системами сборки. Предлагается неинтруизивный подход в построении менеджера зависимостей для С/С++ и с обсуждением <a>cdist</a> в качестве модельной реализации данного подхода.

1. Менеджер
зависимостей для С++
Руслан Муллахметов

2. Проблемы С++
Как превратить кучу кода в исполняемый
файл?

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

4. Системы сборки
shell files
make
autotools
scons
cmake
biicode (?)

5. Процесс сборки в высшей степени
зависит от окружения
разработчика в момент сборки

6. Проблемы систем
сборки
Лишь проверяют, что сборка возможна
check for XYZ …. ok
Нет гарантий на предсказуемость сборки
/usr/local/include
etc

7. Транзитивные
зависимости
A B C
???

8. Менеджер
зависимостей

9. Реазлизации
biicode (закрылся)
clibs (включает код в source tree)
что-то еще?

10. Неудача biicode
собственное хранилище исходного кода
(дублирование VCS)
Отсутствие предсобранных пакетов
Единый репозиторий - отсутствие
децентрализации

11. Два подхода
Универсальное решение для полного цикла
сборки (интрузивный)
Только разрешение и доставка зависимостей
(неинтрузивный)

12. Требования
Подготовка окружения к сборке
Независимость от системы сборки
Активное использование VCS
Децентрализованная архитектура по модели git
Возможность использования предсобранных
пакетов для ускорения времени сборки
контроль конфигурациями зависимостей

13. cdist
прототип
использует git для хранения репозитория
пакетов
разрешает транзитивные зависимости
не поддерживает опции и сборку между
репозиториями
хранит описание пакета в yaml формате

14. libfoo
example.com/foo/foo.git <local-dir>/foo/cdist.yaml
.
├── Makefile
├── include
│ └── foo.h
└── src
└── foo.cpp
id: foo
version: 0.0.1
source: git://example.com/foo/foo.git
build:
- make
- "make install DESTDIR={{DESTDIR}} PREFIX="
export:
include_dir: "{{DESTDIR}}/include"
library_dir: "{{DESTDIR}}/lib"
library: foo
<local-dir>/foo/ myregistry.com/registry.git
$ cdist add .
.
├── foo
│ └── 0.0.1.yaml
└── readme.md
1 2
3 4

15. bar
<project-dir> <project-dir>/cdist.yaml
.
├── Makefile
├── include
│ └── foo.h
└── src
└── foo.cpp
id: bar
version: 0.0.1
source: .
deps:
- foo@0.0.1
build:
- mkdir -p build
- "cd build && cmake .. '-
DCMAKE_SYSTEM_INCLUDE_PATH={{#INCLUDE_DIRS}}{{x}};
{{/INCLUDE_DIRS}}' '-
DCMAKE_SYSTEM_LIBRARY_PATH={{#LIB_DIRS}}{{x}};{{/
LIB_DIRS}}'"
- "cd build && make"
<project-dir> ~/.cdist/index - clone/pull
$ cdist build .
.
├── foo
│ └── 0.0.1.yaml
└── readme.md
1 2
3 4

16. bar (2)
5
6
~/.cdist/cache
$ git clone git://example.com/foo/foo.git foo/0.0.1/src
$ cd foo/0.0.1/src
$ make
$ make install DESTDIR=~./cdist/cache/foo/0.0.1/dest PREFIX=
~/cdist/cache/foo/0.0.1/dest
.
├── include
│ └── foo.h
└── lib
└── libfoo.a
<project-dir>
$ mkdir -p build
$ cd build && cmake .. -DCMAKE_SYSTEM_INCLUDE_PATH=~/.cdist/foo/0.0.1/dest/
include/’ -DCMAKE_SYSTEM_LIBRARY_PATH=~/.cdist/foo/0.0.1/dest/lib/
7

17. Устройство
Пакет
A
Сборка
Артеф
акты
mv
$dir/
Артефакты
+
переменные
Сборка -I
$INCLUDE_DIR
Пакет
B

18. Открытые вопросы
Наследование флагов и дефайнов от зависимостей с
правильным порядком
Использование нескольких версий одной и той же библиотеки
Использование статических и динамических библиотек
Опции для сборок и проблемы возникающие при этом
Релейные и дебажные версии: как определять, как зависеть
C++11 etc
Тесты