О несовершенстве мира

lexa - 25/Ноя/2009 17:16

Второй день собираю Qt 4.6-RC при помощи VS2008, с каким-то очень переменным успехом:

Если собирать Qt SDK, то ломается при сборке вебкита, moc генерирует файл нулевого размера. Ошибка висит в Qt-шном багтрекере со статусом "не удалось воспроизвести", гугление показало что она бывала и на Qt 4.5.2, хотя у меня 4.5.2 собирался без проблем.

Кроме того, не срабатывали такие вот строчки: 

#if QT_VERSION >= 0x040400
    void unsupportedContent(QNetworkReply *reply);
    void downloadRequested(const QNetworkRequest &request);
#endif
хотя версия у меня самая что ни есть 0x040600

При сборке варианта без Qtcreator наблюдался целый ворох странных проблем, тот же moc.exe создавался без прав на исполнение. По десятому разу вроде полегчало и конкретный WebKit вроде собрался без ручных пинков (с пинками, т.е. подменяя файл длины на нормальный - получалось и в первом случае, но неаккуратненько).

Одновременно узнал про jom, на 4-ядерном процессоре ошибки компиляции возникают вчетверо быстрее, ура!

Я вот как подумаю, сколько сил стоит поддержка Qt на всем чудовищном мировом зоопарке, так мне сразу хочется год эдак в 85-й.

Comments

poige (not verified) - 25/Ноя/2009 18:22

> так мне сразу хочется год эдак в 85-й.
Если бы вы знали, как они пи%$@# крокодилов ©

:-)

lexa - 26/Ноя/2009 09:20

Re: > так мне сразу хочется год эдак в 85-й.

Крокодилы - крокодилами, но вот у меня при параллельном make (причем, это их же jom) оно собирается не вполне уверенно, нужно несколько прогонов.

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

ostapru (not verified) - 28/Ноя/2009 08:06

Re: > так мне сразу хочется год эдак в 85-й.
> Я подозреваю, что за счет скорости машины и параллельности - у некоторых файлов получается одинаковое время, отчего портятся зависимости.

Угу. Я тоже что-то подобное подозревал.
Но почему такое случается только у MS VC ? Даже с pvmgmake (при нормально написанных мэйкфайлах) при количестве ядер 11х4 + 2х8 всё работает нормально.
Incredibuild как то тоже решает эту проблему.

lexa - 28/Ноя/2009 09:29

Re: > так мне сразу хочется год эдак в 85-й.
С интеловским компилятором примерно та же беда. Проблема, как мне кажется, в nmake а не в компиляторе.
Ну и в том, что компилятор может всосать десяток файлов, пожевать и быстро сгенерировать код (секунды точно будут те же)

ostapru (not verified) - 28/Ноя/2009 19:52

Re: > так мне сразу хочется год эдак в 85-й.
> Проблема, как мне кажется, в nmake а не в компиляторе.

Угу. С гнусным мэйком и МС компилятором всё Ок.

> Ну и в том, что компилятор может всосать десяток файлов, пожевать и быстро сгенерировать код (секунды точно будут те же)

Да это фигня ;)
Сейчас посмотрел на билд pvmgmake - количество файлов с совпадающими секундами - куча. Написал программку и нашел 5 пар с полностью совпадающим временем в одной и той же директории.
Вроде

-rw-r--r-- 1 user grp 214148 2009-11-28 03:48:17.103485000 -0500 moc_dialogsprovider.o
-rw-r--r-- 1 user grp 122192 2009-11-28 03:48:17.103485000 -0500 moc_messagebox.o

Где больше вероятность получить одинаковый тайм стамп - на распределённом билде с 60ю ядрами или на одной машине с 4мя? Даже учитывая некоторый overhead на запуск процесса у pvmgmake. IMHO, время компиляции на порядки больше, чем запуск процесса. Во всяком случае полный билд небольшого проекта (~1000 файлов) на Q6600 из MS VS 2005 (/mp on,pdb off) и гну мэйком (-j8) разницы никакой не даёт (то один быстрее на пару секунд, то другой).

Проблема именно в nmake (и в самом MS VS), т.к. оно иногда не правильно перекомпилирует, если поменял много файлов разом.

lexa - 28/Ноя/2009 20:15

Re: > так мне сразу хочется год эдак в 85-й.
Если не рассматривать гипотезу багов (хоть она и вероятная), то разница может быть в порядке обхода дерева. Обходящий "в глубину" имеет больше шансов нарваться, как мне кажется.

ostapru (not verified) - 28/Ноя/2009 23:50

Re: > так мне сразу хочется год эдак в 85-й.
ХЗ
Главное, что мы не одни такие и, скорее всего, это не наш баг, что проекты в MS VS иногда не строятся нормально на многоядерных машинах.