Использование gcc вместе с ccache - PullRequest
1 голос
/ 15 сентября 2009

Я думал об использовании ccache со скомпилированным кодом gcc на базе всей команды (один и тот же кеш ccache будет использоваться всеми разработчиками на одной машине).

Поскольку речь идет о коммерческом продукте, «правильность» компиляции является главным приоритетом.

А вот и вопросы:

  1. Является ли компиляция с использованием ccache безопасной / воспроизводимой ? Существуют ли исключительные ситуации, когда ccache допускает ошибочное попадание в кеш.

    Если я извлечу исходный код и скомпилирую его, я ожидаю получить те же продукты (точно такие же библиотеки / двоичные файлы) каждый раз, когда я повторяю новый процесс компиляции. Это должно для коммерческого продукта.

  2. Существуют ли открытые / коммерческие продукты, использующие ccache, являющиеся неотъемлемой частью их построить систему? Это поможет убедить моих коллег использовать ccache.

Спасибо

Ответы [ 2 ]

6 голосов
/ 15 сентября 2009

Согласно своему руководству, ccache определяет, скомпилирован ли он какой-либо объект ранее, по следующему:

  • вывод препроцессора при запуске компилятора с -E
  • параметры командной строки
  • реальный размер компилятора и время модификации
  • любой вывод stderr, сгенерированный компилятором

Если некоторые PHB все еще беспокоятся о предполагаемом риске, который вы принимаете из-за ccache, используйте его только для сборок разработки и постройте конечный продукт, используя компилятор без какого-либо внешнего интерфейса. Или вы можете очистить кеш перед сборкой конечного продукта.

Обновление: Я не знаю о продуктах, использующих ccache как неотъемлемую часть их системы сборки, но это действительно тривиальная интеграция в любую среду, где вы можете задать путь компилятора. То есть для autoconf:

CC="ccache gcc" ./configure

И, посмотрев на имя автора, я бы сказал, что вполне безопасно предположить, что оно широко использовалось в команде Samba.

Обновление в ответ на комментарий Рингдинга об использовании stderr: С точки зрения ccache, один интересный бит информации - это версия и строка конфигурации компилятора C. gcc выводит это в стандартный файл ошибок:

$ gcc -v 2>err
$ cat err
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-2' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-2)

Держу пари, что ccache использует этот или аналогичный вывод. Но, эй, вы всегда можете посмотреть на его исходный код. : -)

0 голосов
/ 16 июля 2012

Я лично знаком только с ccache, который очень прост в использовании, и я нахожу его чрезвычайно полезным для моих крупных частных проектов. Однако, что касается коллективной базы, у меня пока нет опыта. Вы также можете быть заинтересованы в AO (проверенные объекты) :

В целом:

  • обеспечивает более надежный механизм, может использовать распределенную среду для кэширования
  • ccache ускоряет только время компиляции, в то время как AO также ускоряет время соединения.
  • не ограничивается только c / c ++

Вскоре после моего опубликованного ответа (1,5 года назад ...) мне удалось убедить наших менеджеров по сборке и R & D интегрировать ccache в систему автоматической сборки, и они мне за это благодарны. В компании работают более 200 разработчиков, поэтому она действительно работает. Что касается фазы связывания, это все еще проблема.

...