From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 9 Feb 2012 10:14:28 +0400 From: Alexey Tourbin To: ALT Linux Team development discussions Message-ID: <20120209061427.GA15463@altlinux.org> References: <20111221122555.GA32287@mail.truecrux.org> <4EF1D833.7030304@altlinux.org> <20111221183730.GA24356@dad.imath.kiev.ua> <4EF301D0.6060609@altlinux.org> <20111222205611.GA16904@dad.imath.kiev.ua> <11aca36c3406b4e751293dfd65270a50@office.etersoft.ru> <20120128001938.GA15519@altlinux.org> <20120201174747.GA4025@altlinux.org> <20120201185758.GA9858@altlinux.org> <20120202003649.GA15652@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120202003649.GA15652@altlinux.org> Subject: [devel] ccache(1) to prop things up X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 06:14:28 -0000 Archived-At: List-Archive: List-Post: On Thu, Feb 02, 2012 at 04:36:49AM +0400, Alexey Tourbin wrote: > Но эта система была направлена на строгий учет изменений и контроль > целостности репозитория. А реализовать ее не удалось, потому что это > требовало сборочных ресурсов, которые оказались фирме альт линукс не по > карману. Возможно, стратегической ошибкой было и то, что мы не хотели > использовать ccache(1) по крайней мере для тестовой пересборки, а это > могло бы значительно удешевить процесс. Когда в 2002 году ab и sb разрабатывали sandman (прототип сборочной системы), они предлагали, насколько я помню, монтировать внутрь чрута глобальный раздел с ~/.ccache. На это есть два возражения. С точки зрения безопасности это дает интерференцию между пакетами. С точки зрения распределенной архитектуры это требует синхронизацию кеша. Оба возражения снимаются, если для каждого пакета поддерживать персональный "сикеш". Более того, поскольку сборка пакета идет обычно идет в каталоге ~/RPM/BUILD/%name-%version, а при компиляции с флагом -g учитываются пути к исходным файлам, то персональный сикеш можно сразу же ограничить не только именем пакета, но и версией. То есть можно было бы сделать файлы типа ccache/%name-%version.tar.gz, и гонять их зад-назад вместе с src.rpm. Если преследовать еще более строгую схему, которая исключает влияние сикеша по крайней мере на "настоящие" пакеты, которые поступют в репозиторий, то можно сделать следующее. Пакеты всегда собираются через сикеш. Сборка "настоящего" пакета (внутри задания) просто будет выполняться при пустом ~/.ccache (фактически в режиме write-only), но результат сохраняется для последующих тестовых пересборок (в режиме read-write). Я проделал некоторые замеры. Повторная сборка elinks с сикешем идет примерно на 20% быстрее, а повторная сборка apt - в 2 раза. То есть наибольшая выгода, очевидно, будет на больших пакетах с Си++ кодом. В первом приближении (пальцем в небо) сикеш может ускорить тестовую пересборку репозитория в 2 раза.