Ускорить процесс сборки

Кстати, статистика проекта:
1235 файлов 68 папок

 

device

Я в шоке. Команды годами пишут проекты примерно такого размера. Это что сборная солянка из огромного кол-ва других проектов?

Qt4 компилиться 2 часа, и они гады об этом не сообщают, а не плохо бы.

 

device

Фигасе... Автогенерируемый код что ли?

 

reactos 8-10 минут, 152 метра =)

 

"В некоторых группах найдены интересные альтернативы инструментам проверки зависимостей.
Так, группа, работающая над Microsoft Word, выяснила, что полная сборка всех исходных
файлов проходит быстрее, чем выполнение всесторонней проверки зависимостей с помощью
make при условии оптимизации самих исходных файлов (в частности, содержимого
заголовочных файлов и т. п.). При таком подходе средняя машина разработчика Word может
полностью собрать исполняемый файл Word — а это несколько миллионов строк
кода — примерно за 13 минут."

Стив МакКоннел, Совершенный код.

 

Простой тест.

архивируем ZIP файл 1GB

А потом 1000 файлов по 1 Мб


Время архивации разительно отличается !

 

Нет, это Native Code.

Роль автогенерации ничтожно мала. Так, при написании такого модуля как "libsence3d", размером в 3 МБ, кое-чем был сгенерирован вспомогательный код размером в 695 КБ.

P.S.: Попробуйте под FC4 собрать KDEBINDINGS полной комплекции. Сборка закончится на следующий день.

 

А насчет командной разработки --- писала пара человек сюда библиотеку libbotcollection.
1. Положительный результат - боты получились отличные, умные, живучие.
2. Отрицательный результат - см. письмо дяди Федора из Простоквашино

Разработчики не читают, что писали до них.

 

device
Проект собираете под студией?
Дело в том что руками из консоли проект собирается быстрее чем под студией.

 

Чукча не читатель - Чукча писатель

 

нет, из консоли.
Из студии даже никто не решается (рука не поднимается)

 

device

Попробуй для эксперимента указать полный путь к этой библиотеке. Возможно следует оптимизировать содержимое $PATH, -I, -LIBPATH, ...: исключить лишнее для каждого проекта, поменять порядок так, чтобы первыми шли наиболее часто используемые директории и содержащие меньше файлов. Точнее первыми надо помещать директории для которых (популярность/кол. файлов) больше.

Проверь также, правильно ли употребляются "" и <> для инклудов.
Можно также творчески использовать precompiled headers. Если некоторе подмножество тяжёлых h (необязательно чужих) является общим для группы cpp, то надо поместить его в отдельный pch. Можно использовать несколько pch в одном проекте, а также общие pch для несколький проектов. Но таким образом можно сделать хорошо юзеру и плохо себе: уменьшить время полного ребилда но увеличить время билда, если в pch попадут часто редактируемые h.

 

Какой pch, речь как я понимаю о *nix'e.

 

В Win32, но юзаю GCC

 

device
gcc тоже поддерживает precompiled headers.

 

Я знаю.