[devel] task build

[Led]

On Thursday, 19 February 2009 12:17:46 Alexey Tourbin wrote:
> On Thu, Feb 19, 2009 at 11:52:44AM +0200, Led wrote:
> > On Thursday, 19 February 2009 11:47:22 Alexey Tourbin wrote:
> > > On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> > > > А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО
> > > > последовательно?
> > >
> > > А в каком порядке их следовало бы обрабатывать?
> >
> > Параллельно
>
> А как потом сводить?  Если задать жесткие условия сериализации,
> то при параллельной сборке N заданий придётся заново пересобирать
> остальные N-1 заданий.

Что "сводить"? Задания сами по себе друг от друга не зависят (?). если 
какие-то пакеты зависят от последовательности сборки, то они находятся в 
одной task (а внутри task'а уже пакеты собираются последовательно)

>
> А более или менее жесткие условия сериализации нужны для проверки
> целостности: мы переводим репозитарий из состояния S_k (текущего)
> в состояние S_{k+1} (новое).  Нельзя переводить репозитарий сразу
> в несколько новых состояний.

Переводить - последовательно. А собирать (в смысле - выполнять сборочные 
task'и) - параллельно.

> Поскольку возможна интерференция между 
> новыми состояниями.
>
> > > > И, кстати, сборка производится всё ещё с принудительным "--nprocs 1"?
> > > > Почему?
> > >
> > > Чтобы получить хороший лог сборки.  При nprocs более 1 в логе сборки
> > > вывод разных команд обчно перемешивается случайным/нерегулярным
> > > образом.
> >
> > И ради этой сомнительно-полезной "красивости" тратить 2 часа на сборку
> > пакета вместо 20-30 минут? Забавно...
>
> Лог сборки будет храниться, а при тестовой пересборке -- обновляться.
> Короче, должна быть опредлённая структура, которая фиксирует все
> изменения пакетов,

Т.е. git для "фиксации изменения пакетов" - недостаточен?

> как "фактические" изменения (когда заливают новую 
> версию), так и "тестовые" (когда идет тестовая пересборка существующих
> пакетов).

Не вижу причин считать "тестовые пересборки" Священной коровой. ИМХО 
полезность и самодостаточность "тестовых пересборок" сильно преувеличена: 
неоднократно натыкался на случаи, когда после формально успешной пересборки 
пакет не то что не работал, а даже не устанавливался (в частности, из-за 
изменившихся автоматически полученных Require'ов).

-- 
Led