Size: a a a

2020 October 07

LB

Let Eat Bee in DevOps
Даже с CGO?
источник

SP

Sergei Puzyrev in DevOps
Let Eat Bee
Даже с CGO?
даже с CGO, если ты собираешь артефакты до cgo тоже герметично.
базелю насрать на то КАК ты собираешь.
сборкой может быть wget && tar xvzf && cp
просто от каждого шага сборки он требует полную идемпотентность. поэтому wget url && tar && ./configure $FLAGS && make - это идемпотентно, если ./configure не вылазит наружу из песочницы.
источник

LB

Let Eat Bee in DevOps
Sergei Puzyrev
даже с CGO, если ты собираешь артефакты до cgo тоже герметично.
базелю насрать на то КАК ты собираешь.
сборкой может быть wget && tar xvzf && cp
просто от каждого шага сборки он требует полную идемпотентность. поэтому wget url && tar && ./configure $FLAGS && make - это идемпотентно, если ./configure не вылазит наружу из песочницы.
Вот тут и начинается дистр, что б собирать апстрим надо часто патчить - пути или флаги линкера или ещё что-нибудь
источник

SP

Sergei Puzyrev in DevOps
Let Eat Bee
Вот тут и начинается дистр, что б собирать апстрим надо часто патчить - пути или флаги линкера или ещё что-нибудь
в реальности это очень ограниченно
источник

LB

Let Eat Bee in DevOps
Хз, я когда в альтлинукс мейнтенил пакеты насмотрелся всякого
источник

SP

Sergei Puzyrev in DevOps
пакеты мейнтейнить куда сложнее
источник

SP

Sergei Puzyrev in DevOps
пакеты должны нормально работать друг с другом
источник

SP

Sergei Puzyrev in DevOps
и собираться одним компайлером
источник

LB

Let Eat Bee in DevOps
В чем отличие? В базеле ж тоже должны друг с другом дружить
источник

SP

Sergei Puzyrev in DevOps
Let Eat Bee
В чем отличие? В базеле ж тоже должны друг с другом дружить
вовсе нет
источник

SP

Sergei Puzyrev in DevOps
они должны дружить в рамках единого артефакта сборки
источник

SP

Sergei Puzyrev in DevOps
но тебе никто не мешает собирать из одного репозитория что-нибудь тремя разными голангами
источник

LB

Let Eat Bee in DevOps
Особенно статическая линковка, в половине апстримов она сломана была
источник

SP

Sergei Puzyrev in DevOps
задача же не собрать весь мир, а нормально собрать код, который мы контролируем.
поэтому внешние зависимости заворачиваются через https://github.com/bazelbuild/rules_foreign_cc , а сборка своего кода работает как положено
источник

SP

Sergei Puzyrev in DevOps
технически конечно можно влезть в каждый опенсорс-проект в мире, но зачем?
источник

SP

Sergei Puzyrev in DevOps
не обязательно граф зависимостей распространять на каждый файл в исходниках openssl, если код openssl мы не контролируем. всю их область мы обозначаем одним узлом (openssl) и зависим от него
источник

LB

Let Eat Bee in DevOps
Sergei Puzyrev
задача же не собрать весь мир, а нормально собрать код, который мы контролируем.
поэтому внешние зависимости заворачиваются через https://github.com/bazelbuild/rules_foreign_cc , а сборка своего кода работает как положено
Всякие число дробилки особенно любят разъезжаться. Собрал openblas так, numpy эдак, запускаешь - оно символы или пути  где то как то не находит и ругается. Я конечно с базелом в продакшене не сидел, но не верю что произвольные  апстрим тарболы так уж легко подсасываются
источник

SP

Sergei Puzyrev in DevOps
Let Eat Bee
Всякие число дробилки особенно любят разъезжаться. Собрал openblas так, numpy эдак, запускаешь - оно символы или пути  где то как то не находит и ругается. Я конечно с базелом в продакшене не сидел, но не верю что произвольные  апстрим тарболы так уж легко подсасываются
ты подсосал один тарболл один раз и пока не менял его - оно будет собираться.
источник

SP

Sergei Puzyrev in DevOps
понятно, что если внешние исходники меняются, то оно может разломаться.
источник

SP

Sergei Puzyrev in DevOps
но когда ты заменишь тарболл на новый и сами бласы соберутся - ты сможешь моментально увидеть, что у тебя в монорепе что-то не собирается из-за изменившегося бинарного интерфейса, например.
поэтому тот, кто будет менять блас - не закоммитит это насильно пока не пофиксит.
источник