> Об том и новизна решения.
> Только вот, как только встанет вопрос как демону компилятору сообщить, мол то,
> что компилировал Вася нельзя сообщать Пете, или уж тем более заменять
> тем, который подсунул Петя.Никак. Это не его проблемы. Обычный компилятор совершенно не парится тем, кто компилирует -- Вася или Петя, почему этот должен? Если Вася запустил себе такого демона, то как вообще Петя сможет до него достучаться?
> Или о том что и после перезагрузки
> и на другом узле кластера тоже можно не компилять stdio.h по
> тыще раз на дню если он уже дней сто как не
> меняется. Тут сериализация может быть и полезна. Даже если совершенно не
> будет покидать память.
Видимо, кластерная сборка -- это юзкейс не для этого компилятора? Для кластера надо использовать другой кеширующий компилятор.
zapcc для разработчика, который имея дома восьмиядерную тачку с 32Гб оперативки, тратит по полчаса на каждую пересборку проекта. Тебе не приходилось писать ebuild'ы? Самый убедительный тест ебилда -- это когда emerge отлично отрабатывает этот ебилд. Но если есть замечания по тому, как ебилд отработал, то мы немного исправляем и, таким образом, инвалидируем все предыдущие тесты. Было бы круто ещё раз прогнать ебилд от начала и до конца, но это же ещё полчаса сборки... Но ок, ебилд работает, а будет ли он работать если мы поменяем окружение? Заменим bash на dash, например? Если zapcc может ускорить пересборку в пять раз, значит мы сможем позволить себе в пять раз больше тестовых прогонов ebuild'а.
zapcc для разработчика, который выгребает из почты патчи, просматривает их, применяет, компилирует, подписывает и отправляет в мейнстрим. Если пересборка занимает полчаса, то производительность работы этого разработчика упрётся в скорость компиляции. Если пересборка занимает 5 минут, то компиляция перестанет быть бутылочным горлышком.
zapcc для разработчика, который своими руками что-то твикает в коде, и хочет затем убедиться, что это компилируется и работает, а для этого надо пересобрать весь проект со всеми тестами и посмотреть, что из этого выйдет. И, скорее всего, пересобрать неоднократно, потому что с первой попытки не заработает. А когда оно в конечном итоге заработает, неплохо бы сделать make clean; make, чтобы убедиться, что оно на самом деле собирается -- бывает, что make отрабатывает, а после make clean всё ломается. А иногда оно ломается в результате твиков, и make не отрабатывает, а make clean; make -- справляется.
Вот тебе три примера людей, для которых сериализация будет ненужным усложнением, привносящим дополнительные баги и ненужные тормоза.
