LINUX.ORG.RU

Ищу универсальный ускоритель-распределитель компиляции программ

 , , ,


0

3

Да, идея далеко не новая, есть много разных реализаций. Но у всех есть какие-то неудобные для меня ограничения. distcc не поддерживает отличные от Си/Си++ языки, и, похоже, потребует жонглирования версиями компиляторов, если понадобится собирать что-то разными версиями GCC. Fastbuild, кажется, умеет загружать на удалённые ноды бинарники компилятора, но требует переписать скрипты сборки на своём языке, что не всегда возможно для чужих проектов. Incredibuild обещают волшебство, но условия лицензирования и стоимость для физических лиц непонятны. Даже не вполне ясно, что именно считается у них поддержкой Linux.

Хочу что-нибудь открытое-бесплатное или хотя бы со внятной ценовой политикой. Хочу поддержку распространённых систем сборки типа CMake, Meson и простых Makefile. Желательно, вообще независимость от конкретных систем сборки, чтобы, к примеру, можно было собирать Firefox и Chromium. Хочу чтобы оно автоматически загружало на удалённую ноду все нужные для компиляции файлы включая бинарники компилятора, забирая обратно результаты сборки. Хочу поддержки других языков; как минимум, Rust. Хочу кеширование результатов сборки или прозрачного взаимодействия с ccache. Хочу, чтобы оно не умирало от пинга в 50-100 мс, чтобы можно было ноды поднимать на VPS.

Такое уже существует?

★★★★★

Чтобы было прозрачно (без доработок) и поддерживало все языки и все компиляторы и системы сборки, в т.ч. неизвестные, вариант вижу только один: монтируй локальную фс через nfs на сервер и запускай там компилятор как будто локально. На локальном компе бинарник компилятора подмени на прозрачный удалённый запускатор.

firkax ★★★★★
()
Ответ на: комментарий от firkax

А NFS не встрянет на задержках в 50 мс?

И в этой задаче ведь не нужна файловая система в чистом виде. При сборке есть некие дополнительные гарантии. Вменяемые системы сборки не запускают одновременно две задачи, каждая из которых пишет в общий файл. Поэтому запись не нужно часто синхронизировать, достаточно после отработавшего компилятора забрать результат. Чтение исходных файлов тоже может быть агрессивно кешировано, потому что во время сборки обычно не меняют исходники.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Сетевые задержки разумеется будут, но как я понял речь про тяжёлую компиляцию, где нагрузка на проц важнее.

При сборке есть некие дополнительные гарантии.

Ты ими сможешь воспользоваться, только если спроектируешь свой распределитель нагрузки под конкретную систему сборки. А ты хочешь ни к чему не привязываться - тогда придётся на уровне фс работать и никак иначе. Синхронизировать запись в недописанный (не закрытый) файл возможно и правда не нужно, но это мало на что влияет. Возможно это можно в nfs затюнить.

Ну, можно вместо nfs сделать какое fuse с умной синхронизацией, или скомпилить свой модуль для ядра с тем же, но это всё детали. Сихнхронизация должна быть именно на уровне файловой системы, всякие ручные запуски rsync-ов будет неудобно вставлять в неизвестную систему сборки с неизвестным компилятором.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Вообще да, я представлял себе, что на ноде задачи будут крутиться в контейнерах, где корневой системой будет FUSE ФС, подгружающая файлы по требованию. Про брутфорс подход с тупо монтированием всего по NFS я не думал даже.

Вообще во времена, когда distcc только появился, уже были в ходу надстройки над make, которые среди прочего всего требовали, чтобы все хосты имели доступ к одной общей сетевой ФС. И эти системы сейчас не используют, а используют distcc. Скорее всего, с ними было много проблем, иначе они всё ещё были бы в ходу.

Спасибо за идею. Обязательно попробую. Просто я ожидал, что есть более хитрые решения, наподобие Incredibuild.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от gag

Похоже, это оно.

Не конкретно llama, а проект gg, на который там ссылаются. В презентации (https://www.youtube.com/watch?v=VVWVN6Czji4) упор шёл на выполнение в облаке Амазона, но в статье (https://www.usenix.org/system/files/atc19-fouladi.pdf) мельком упоминаются другие движки, для частных «облаков».

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от pingvinek

У этого подхода тот же недостаток, что и у Fastbuild — сборку придётся переделывать под Nix. И ещё он ориентирован на пакетную сборку, а не на процесс разработки. И будет совсем непонятно в ситуации, когда собирать нужно на конкретном дистрибутиве, например, CentOS 7.

i-rinat ★★★★★
() автор топика
19 февраля 2023 г.

Есть гугловые Remote Execution APIs и сложившееся инфраструктура (перечислена в readme) вокруг них, опенсорсная и коммерческая. В частности, адаптер RECC обещает поддержку протокола в виде обёртки вокруг CC. Я бы смотрел в сторону BuildGrid.

Но всё это очень перемудрено, я вот уже день фрустрирую с тем, как завернуть сборку простейшего bazel helloworld в локальный контейнер.

snizovtsev ★★★★★
()
Последнее исправление: snizovtsev (всего исправлений: 2)

distcc не поддерживает отличные от Си/Си++ языки, и, похоже, потребует жонглирования версиями компиляторов, если понадобится собирать что-то разными версиями GCC

icecc, но он тоже только для C/C++

Упс, некротред.

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.