Второй день собираю 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
<b>> так мне сразу хочется год эдак в 85-й. </b><br/> «Если
> так мне сразу хочется год эдак в 85-й.
«Если бы вы знали, как они пи%$@# крокодилов…» ©
:-)
<b>Re: > так мне сразу хочется год эдак в 85-й. </b><br/> К
Re: > так мне сразу хочется год эдак в 85-й.
Крокодилы - крокодилами, но вот у меня при параллельном make (причем, это их же jom) оно собирается не вполне уверенно, нужно несколько прогонов.
Я подозреваю, что за счет скорости машины и параллельности - у некоторых файлов получается одинаковое время, отчего портятся зависимости.
<b>Re: > так мне сразу хочется год эдак в 85-й. </b><br/> >
Re: > так мне сразу хочется год эдак в 85-й.
> Я подозреваю, что за счет скорости машины и параллельности - у некоторых файлов получается одинаковое время, отчего портятся зависимости.
Угу. Я тоже что-то подобное подозревал.
Но почему такое случается только у MS VC ? Даже с pvmgmake (при нормально написанных мэйкфайлах) при количестве ядер 11х4 + 2х8 всё работает нормально.
Incredibuild как то тоже решает эту проблему.
<b>Re: > так мне сразу хочется год эдак в 85-й. </b><br/> С
Re: > так мне сразу хочется год эдак в 85-й.
С интеловским компилятором примерно та же беда. Проблема, как мне кажется, в nmake а не в компиляторе.
Ну и в том, что компилятор может всосать десяток файлов, пожевать и быстро сгенерировать код (секунды точно будут те же)
<b>Re: > так мне сразу хочется год эдак в 85-й. </b><br/> >
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), т.к. оно иногда не правильно перекомпилирует, если поменял много файлов разом.
<b>Re: > так мне сразу хочется год эдак в 85-й. </b><br/> Ес
Re: > так мне сразу хочется год эдак в 85-й.
Если не рассматривать гипотезу багов (хоть она и вероятная), то разница может быть в порядке обхода дерева. Обходящий "в глубину" имеет больше шансов нарваться, как мне кажется.
<b>Re: > так мне сразу хочется год эдак в 85-й.</b><br/> ХЗ
Re: > так мне сразу хочется год эдак в 85-й.
ХЗ
Главное, что мы не одни такие и, скорее всего, это не наш баг, что проекты в MS VS иногда не строятся нормально на многоядерных машинах.
Post new comment