Идеи для ускорения установки зависимостей
У меня есть проект, который зависит от многих внешних библиотек, таких как GLFW3, GLEW, GLM, FreeType2, zlib и т. Д. Было бы лучше хранить / обмениваться установленными зависимостями между заданиями, чтобы не приходилось загружать / устанавливать их все время, что занимает около половины времени. Я вижу пару идей, как справиться с этим:
а) для каждого задания для каждой сборки загружаем зависимости и устанавливаем их
б) разместить зависимости (источники) в моем репо и иметь небольшое ускорение, потому что мне больше не придется загружать их с внешних серверов (все равно придется скомпилировать и установить их)
в) скомпилируйте их вручную, поместите на какой-нибудь сервер и просто загрузите нужный пакет для каждой сборки
а) мне меньше всего нужно обновлять зависимости для сборки и тестирования, позволяет использовать новейшие версии для сборки моего проекта, но это занимает больше времени (как компиляция, так и загрузка)
б) раздувает репозиторий с дополнительным кодом (не моим), дает небольшое ускорение (загрузка обычно не такая медленная), добавляет ручную работу для обновления зависимостей, я думаю, хуже, чем а)
c) самый быстрый, но требует от меня большей работы, чтобы постоянно обновлять построенные зависимости и загружать их на быстрый сервер (также по-разному для каждой задачи сборки (компилятор и т. д.)), позволяет выполнять самые быстрые сборки (просто скачать & копия / установка).
Итак, как вы управляете своими внешними зависимостями и поддерживаете их в актуальном состоянии для ваших сборок travis?
Обратите внимание, что я использую бесплатную версию Travis, и мне нужно sudo для обновления cmake, gcc и т. Д. И установки зависимостей … Может как-то обмануть CMake, чтобы использовать локальные версии зависимостей вместо / usr / … но это как-то раздувает CMake, который я Верить должно быть очень просто и понятно.
Решение
Давайте назовем весь набор зависимостей вашей сборки в какой-то момент времени зависимостью «цепочка».
Я бы отделился использование (определенной версии) модельного ряда в ваших сборках от задачи обновление версии модельного ряда (когда требуется новая версия зависимости) — смешивание их излишне усложняет картину IMHO (я предполагаю, что многие из ваших сборок будут использовать одну и ту же версию очереди зависимостей).
Давайте посмотрим на использование очереди первый.
Из вашего описания монтаж из (уже построенных) зависимостей является общим для всех 3 опций и выполняется при каждой сборке, поэтому давайте пока отложим это.
Разница между вашими подходами остается только в как вы получаете построенные зависимости:
- — скачивать их с внешних серверов — при каждой сборке
- б — строить их из источников репо — при каждой сборке
- с — скачивайте их с локального быстрого сервера — при каждой сборке
Похоже на то а также с в основном то же самое, за исключением с будет быстрее из-за локального доступа. Более вероятный б будет самым медленным
Так выглядит с является победителем с точки зрения скорости сборки в этом контексте.
Теперь вопрос заключается в том, можно ли / как быстрее выстроить линейку построенных зависимостей на локальном сервере для с подход. Я вижу 2 варианта (не уверен, что они оба возможны в вашем контексте):
- загрузите уже построенные зависимости (как в вашем
подход) с внешних серверов (фактически просто кешируя их на
локальные серверы) - строить зависимости локально из источника, за исключением того, что вам не нужно ни размещать эти источники в том же репо, что и ваш проект, ни создавать их для каждой сборки проекта (как в вашей б подход) — это нужно делать только тогда, когда вы обнови свой модельный ряд (и только для новых версий соответствующих зависимостей).
Вы также можете посмотреть на смешивание двух опций: некоторые зависимости, используя опцию 1, другие используют опцию 2, как вы считаете нужным.
Теперь, если вы используете образы VM (или Docker или аналогичные) для своих машин сборки и у вас есть контроль над такими образами, это может быть можно значительно ускорить сборку, настроив эти образы виртуальных машин — на них установлена линейка зависимостей, что сделает их немедленно доступными для любой сборки на машине, на которой выполняется такой настроенный образ.
Наконец, когда приходит время обновить список зависимостей (который, кстати, должен присутствовать в вашем а также б подходы тоже не только в с 1) вам нужно будет просто загрузить новые версии зависимостей, построить их при необходимости, сохранить встроенные зависимости на локальном быстром сервере и, если вам подходит настроенное решение для образа виртуальной машины, обновить / заново создать настроенный образ виртуальной машины с помощью установка новой линейки зависимостей.
Другие решения