>> Посмотрите внимательно на то, как собирается какой-нибудь проект на Qt, да или
>> вообще плюсах.
> Да нормально более-менее. Если пересобирать 1-2 файла, как это происходит при типовом
> процессе написания программ - проблем никаких. Или вы регулярно перелопачиваете полпроекта?
> А потом не задалбывает разгребать полпроекта то с вопросом "ой, где
> же я накосячил?"

Не обязательно перелопачивать пол-проекта, чтобы их пришлось перекомпилировать, достаточно поменять особо "популярный" хедер. Но и даже если ограничиваться модулями (типа .cxx), время тратится заметно.

>> Сколько времени занимает компиляция каждого объектного файла,
> Ну, несколько секунд, максимум. Учтя что при обычной пересборке проекта меняется 1-2
> файла - компил и линковка укладывается в несколько секунд.

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

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

"И на том спасибо, добрый человек. А можно чуть конкретнее?", - к/ф "Ширли-мырли"

>> И да, опции "-O0 -ggdb" не забудьте, ибо они
>> при разработке как раз используются. Бинарники на сто мегабайт, думаете, в
>> мгновение ока записываются?
> Именно так: дисковый буфер любой современной машины больше 100Мб. Бинарь просто вываливается
> в него как в бездну, мгновенно. По той же причине линковка
> того что мы линковали минуту назад - испытывает аццкий cache hit
> и диск почти не озадачивается. А програмер использующий рухлядь где недостаточно
> места в памяти но при том ворочающий 100Мб бинари при этом
> - очевидно ССЗБ. Такое сочетание куда типичнее для задротов пересобирающих себе
> всю систему с поводом и без.

Спасибо, вот теперь видно, что программированием всерьёз вы не занимаетесь. Потому что даже не понимаете, о чём говорите. Вы кроме как пропускной способности дискового интерфейса, вообще никаких причин для тормозов не видите, не? Надо рассказать, из чего эти мегабайты состоят и как формируются?

>> А цикл "сборка-запуск" при разработке нередко раз в
>> несколько минут, а то и ещё чаще, выполняется.
> Это что, разработка либрофиса на первом пентиуме с 16Мб оперативки чтоли? У
> меня за несколько минут соберется, пардон, ВЕСЬ довольно крупный проект на
> си++, с нуля. Типа battle for wesnoth или там qutim например,
> если уж мы о плюсах.

qutim? Крупный проект? Убили наповал. :)) А насчёт игр - вы размер проекта чем меряете, мегабайтами дистрибутивного пакета? А если выкинуть ресурсы? ;)

>> А где-то фэйлит GCC, и что? Только у LLVM-компиляторов ещё и задел
>> больший, и прогрессируют быстрее.
> Это шланг фэйлит - см на форониксовых тестах что и где. Гсс
> сфэйлил всерьез только 1 раз. Точнее, это Open64 словил Epic Win
> дружно обставив шланг и гцц на амд в разы. Но к
> сожалению оно вообще не осиливает генерить код под интел и поэтому
> даже такой эпичный вин ему обеспечит как максимум сильно нишевое применение
> (и то, там где битва за скорость числодробления до упора -
> GPU всяко перспективнее).

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

>> А причём тут вообще задроты? Компилятор - инструмент разработчика. Чем собирает
>> разработчик, тем будут собирать и все остальные.
> Будут. Или не будут. Зависит от. Ну вот например собирает разработчик программу
> вьюжлом. А под опенок его бац и нету. Соберут тем чем
> собирается, что есть и не создает лишних проблем или забьют.

Теоретически такое возможно, да. А к реальности не хотите вернуться?

P.S.: Насчёт "не создаёт лишних проблем" - это, как вы говорите, уже окончательный epic fail с вашей стороны.