Когда-нибудь задумывались, зачем в билд-системах команда clean? То есть, понятно, почему она в них была, но почему она до сих пор есть? Почему иногда билд собирается только с чистого листа
( Read more... )
nixos это все-таки целый дистрибутив. То есть слишком уж радикальное изменение. А сам nix можно использовать отдельно в любом дистрибутиве, и в мак оси тоже.
docker run docker2.dev.flocktory.com:5000/widget:0875e4456f8addd3542d1c06f2bef11b7a8e39ea
И так от любого коммита. Есть команда, которая запустит все нужные контейнеры для прогона тестов. Все изолировано.
И, довольно пофиг, выполняется билд 2 секунды или 300, все в ci, доступно любому разработчику в одну команду. Инкрементальность, в определенной степени, обеспечивает докер (без изменения зависимостей поменяется только слой, отвечающий за сам код, если изменились, то и слой с зависимостями изменится, все автоматически, без участия человека).
Прости, Андрей, просто меня раздражает хайп вокруг докера, явно непропорциональный не то чтобы его достоинствам, но даже его потенциалу. Ты просто под руку подвернулся первым :)
Понятно что если делать make clean вообще всегда жить станет проще и веселей. Но это нереалистичное количество времени для таких языков как C++. Да что там, меня даже в boot раздражает что он ничего не помнит при перезапуске, хотя у меня полный билд 45 cек. Я хочу 1 секунду.
Докер явно не подходит на роль менеджера иммутабельных зависимостей, потому что у него дерево растет не в ту сторону. У него от базового образа можно отнаследовать N детей, а в сборке надо наооборот конечный образ отнаследовать от N базовых. Т.е. единственное когда он подходит - когда билд строго линеен. Что в жизни не встречается.
Использование mtime, оно хоть теоретически и грязно, но на практике я не припомню чтобы подводило. Ну если не играться с системным временем и не использовать vcs которые его ставят в прошлое при чекауте. Главное - это вот:
> окружения, версии компилятора, флагов
и тут уже полный ад творится. В том числе, например, и то что при параллельной сборке "окружение" на входе может меняться случайным образом. Вот, например, такое бывает: http://max630.livejournal.com/217018.html
Ну и дело не в инструменте, на басе makefile всё может работать как часы, наверное даже msbuild можно использовать правильно. Просто депенденсы всегда прописаны как попало, плюс что-то где-то генерится, и там всё ещё хуже, и может даже меняется существуещее, что совсем плохо
> Использование mtime, оно хоть теоретически и грязно, но на практике я не припомню чтобы подводило. Ну если не играться с системным временем и не использовать vcs которые его ставят в прошлое при чекауте.
Это размен по мелочам. Мы чуууууууть чуууууууууть выиграем в скорости, но потеряем кучу возможностей: пайплайны (A->B->C, A поменялся, но B сгенерировался такой же, C можно не билдить), распределенный кэш. Плюс у него точность секундная, поэтому опять же может что-то пропустить. Надо думать не о том, что вау вау оптимизация, скорость, скорость, а о том, купит она нам счастье или нет. Эта - не купит.
Comments 43
Reply
Reply
PS Хотя там не все идеально пока, побитное сравнение двух сборок с одинаковым хешем тебе никто не гарантирует (хотя над этим тоже работают)
Reply
Reply
Reply
ccache же
хотя те у кого вижуал студия - те не пришли, да
Reply
Нормальным С++ людям эта схема просто не нужна, у них и так скорость итерации сравнима с Питоном.
Reply
Reply
Reply
И так от любого коммита. Есть команда, которая запустит все нужные контейнеры для прогона тестов. Все изолировано.
И, довольно пофиг, выполняется билд 2 секунды или 300, все в ci, доступно любому разработчику в одну команду. Инкрементальность, в определенной степени, обеспечивает докер (без изменения зависимостей поменяется только слой, отвечающий за сам код, если изменились, то и слой с зависимостями изменится, все автоматически, без участия человека).
Reply
Reply
Быстрые с точки зрения доставки новых версий со всеми зависимостями, да. Скачивая, только последний слой.
А ставить диагнозы это круто, да.
Reply
Понятно что если делать make clean вообще всегда жить станет проще и веселей. Но это нереалистичное количество времени для таких языков как C++. Да что там, меня даже в boot раздражает что он ничего не помнит при перезапуске, хотя у меня полный билд 45 cек. Я хочу 1 секунду.
Докер явно не подходит на роль менеджера иммутабельных зависимостей, потому что у него дерево растет не в ту сторону. У него от базового образа можно отнаследовать N детей, а в сборке надо наооборот конечный образ отнаследовать от N базовых. Т.е. единственное когда он подходит - когда билд строго линеен. Что в жизни не встречается.
Reply
> окружения, версии компилятора, флагов
и тут уже полный ад творится. В том числе, например, и то что при параллельной сборке "окружение" на входе может меняться случайным образом. Вот, например, такое бывает: http://max630.livejournal.com/217018.html
Ну и дело не в инструменте, на басе makefile всё может работать как часы, наверное даже msbuild можно использовать правильно. Просто депенденсы всегда прописаны как попало, плюс что-то где-то генерится, и там всё ещё хуже, и может даже меняется существуещее, что совсем плохо
Reply
Это размен по мелочам. Мы чуууууууть чуууууууууть выиграем в скорости, но потеряем кучу возможностей: пайплайны (A->B->C, A поменялся, но B сгенерировался такой же, C можно не билдить), распределенный кэш. Плюс у него точность секундная, поэтому опять же может что-то пропустить. Надо думать не о том, что вау вау оптимизация, скорость, скорость, а о том, купит она нам счастье или нет. Эта - не купит.
Reply
Reply
Reply
Leave a comment