Кто может объяснить, почему webkit-gtk так долго компилируется?

У тя слишком долго жирнолис компилируется чё-то. Перепиши вебкит без шаблонов, будет тебе счастье.

У тя слишком долго жирнолис компилируется чё-то.

так это в рабочее время, я параллельно в хроме тусовался, торренты кочал и музыку лосслесс слушал, а вот в случае с вебкит-гтк, то процессорное время было отдано полностью на сборку пакета.

шаблоны... те кто все еще юзают 32 бита зачастую и собрать-то не могут - тупо адрессного пространства не хватает

про шаблоны уже сказали. кроме этого огнелис при сборке ccache использует, что тоже изрядно время при повторных сборках сокращает

Ясно, спасибо.

выпили его и не парься :)

я его полтора часа впиливал, чтобы посмотреть на, в итоге оказавшийся негодным, Shotwell.

Зачем такие страдания?

а чем еще картинки сортировать по тегам?

Я, собственно, об полторачасовой компиляции чтобы просто посмотреть приложение.

а, ты имеешь в виду, почему бы не запустить ливсиди убунты или федоры и просто глянуть изображение? Ты прав, я жестко протупил.

ld.gold поставил?

тогда нет, вот сейчас поставил, реально быстрее будет компилироваться?

я использую для этого файловый менеджер

В основном от навороченности компилятора зависит (версия, предпринимаемые оптимизации, выделенная память под компиляцию, механизмы кэширования файлов с диска). И ещё программы на C++ очень долго компилируются (по сравнению с программами на C, Java, например). Почему? Шаблоны должны быть раскрыты компилятором в многокилометровые простыни, установлены многочисленные статические связи между объектами кода - это давняя ошибка модуляризации C/C++, так они от этого и не отошли. Например, в отличие от Borland Pascal и Sun Java, где модульность стоит на первом месте и не нужно всю программу представлять одной большой «простынёй» в памяти и ходить по ней, строя результирующий бинарный код, модули компилируются отдельно, линковка осуществляется между готовыми бинарными объектами из ранее скомпилированных модулей — .TPU/.BPU, .class, соответственно. В Java линковка кода из модулей осуществляется в рантайме по понятным причинам, в C/C++ для статической линковки придумали .OBJ, .o, для динамики — .DLL, .so, но всё равно и этого недостаточно — компилятору необходимо знать о коде программы на C/C++ ВСЁ, чтобы построить правильный бинарник, и программа могла правильно работать. Из-за этого и ТОРМОЗААА.

FreeBSD 11.0-PRERELEASE компилируется 4 часа 30 минут на AMD Phenom II X4 810 и 12 ГБ ОЗУ. И это ещё только самое необходимое из системы — всё лишнее на десктопе поотключал в src.conf, убрал опции отладки. Примерно 3 часа компилируется один только LLVM/Clang 3.8.0 из состава системы - больше всего напрягает. (Накой чёрт его в состав системы включили? Использовали бы бутстрап из соответствующего порта.)

Твой файловый менеджер может показать рекурсивно все картинки из директории, в которой содержатся еще другие директории с картинками?

ясно, спасибо.

merge time: 1 hour, 35 minutes and 14 seconds

нашёл, о чём жаловаться

я порты собирал, так у меня там аж три штуки вебкитов, то вебкит, то вебкитгтк, то ещё что-нибудь. суммарно пять суток компилировались

легко

только мне это никогда не пригождалось

кроме этого огнелис при сборке ccache использует

Как это включить? Недавно делал bisect, так после каждого шага почти всё заново пересобиралось из-за unified sources. Меняется один файлик, а пересобирается вся связка.

Раньше был ключ, но он сейчас не работает.

как называется файловый менеджер?

там ведь можно не иконками, а тхумбнейлами, например 256х256 и такого типа, да?

dolphin

да, можно

Потому что компиляющие без причины должны спонсировать разработку процессоров.

«ac_add_options --with-ccache» в .mozconfig

Не-е, так всё равно используются Unified_*.cpp.

возможно. ccache может не сработать в случае определенных флагов компилятора. кроме этого, он хранит время, и если эти файлы перегенерируются или им touch делают - время их модификации будет более свежее, чем у собранного кэша, и в этом случае опять будет запущена пересборка

У меня ccache установлен и постоянно включен.

С исходниками Firefox проблема в другом. Они уже давно не собирают файлы по отдельности. Вместо этого несколько cpp файлов склеиваются в один — создаются файлы типа Unified_cpp_widget0.cpp, в который includ'ятся исходники. Компилируются уже эти Unified_*. При сборке с нуля такая склейка полезна, но при bisect'ах это сплошное мучение. Меняются несколько файлов, и все задетые Unified_* компилируются заново. Почти все шаги bisect'а, кроме последних двух-трёх, это сборка всего Firefox заново.

У них есть какой-то режим, где объектники скачиваются из их артифактория, но я хочу быть уверенным, что сборка была моей версией компилятора, что бы не разгребать шальные баги от каких-то несоответствий.