Здравствуйте, гость ( Вход | Регистрация )
Tonal | Дата 29.6.2009, 10:40 |
При компиляции PyQt ключик -j нормально работает в mingw32-make. Я правлю руками makefile сгенерённый при configure. Правда при этом я убираю SH из путей - PyQt с ним не компилиться. А вот при компиляции самой Qt ключик не работает. Почему - не знаю. |
|
SABROG | Дата 29.6.2009, 8:15 |
similar Аналогичный переключатель как и у GNU Make. Я нигде не нашел упоминания о том, что его можно использовать с MinGW. |
|
Litkevich Yuriy | Дата 29.6.2009, 4:16 |
у mingw32-make не работает ключ -j, в отличае от make в MSYS Цитата jom is a clone of nmake to support the execution of several commands at once. тыкIt adds the -j command line switch similar to GNU make. |
|
SABROG | Дата 27.6.2009, 17:51 |
А время сборки как-то заметно изменилось? Я как-то не замерял, т.к. в прошлый раз на ночь оставлял, а на этот раз собралось часа за 2. Кстати дизайнер у меня затребовал еще файлик libgcc_s_dw2-1.dll помимо mingwm10.dll. Во Цитата - Dynamic linking with libgcc_s_dw2-1.dll Dynamic linking with libgcc_s_dw2-1.dll is necessary to throw exceptions between different modules, such as between two DLLs or a DLL and an EXE. Consequently, it is the default for all languages other than C. To disable this dynamic linking, use -static-libgcc. To enable this dynamic linking in C, use -shared-libgcc. Т.е. теперь и его чтоль тянуть надо всегда? |
|
Litkevich Yuriy | Дата 27.6.2009, 17:09 |
А время сборки как-то заметно изменилось? | |
SABROG | Дата 27.6.2009, 16:15 |
Собрал Qt новым MinGW. Для интереса сравнил размеры файлов, которые получились от старого и нового gcc. Общая сумма размеров файлов на: старом: 363Мб новом: 514Мб Если брать отдельные версии сборок, то релизные dll'ки в сумме составили на: старом: 52Мб новом: 39Мб дебажные на: старом: 310Мб новом: 474Мб Т.е. оптимизация по размеру улучшена. По скорости, к сожалению, сравнить не могу. |
|
Litkevich Yuriy | Дата 27.6.2009, 14:50 |
(прокрутку окна обратно не далеко делает) а ты через свойства окна поменяй. |
|
SABROG | Дата 27.6.2009, 12:48 |
Хорошо, если троли решили эту проблему, то зачем bash, собирал бы в cmd? Вот сижу и собираю. Тока у cmd слабый скриптинг, мелкий размер буффера (прокрутку окна обратно не далеко делает) и у mingw32-make не работает ключ -j, в отличае от make в MSYS, который может запускать параллельно несколько компиляций и дожидаться завершения одной из них, если они зависимы. |
|
Litkevich Yuriy | Дата 27.6.2009, 12:40 |
Хорошо, если троли решили эту проблему, то зачем bash, собирал бы в cmd? | |
SABROG | Дата 27.6.2009, 11:24 |
Даже нашел место откуда ноги растут: ты мэйкфайл смотри. Что за пути странные с собакой??Вот смотри у тебя Windows 2000 и на ней не собирается WebKit, так? А не собирается он из-за ограничения в длинне параметров для программ командной строки в виндах младше WindowsXp. Тролли решили это дело пофиксить через добавление специального ключа @, через который можно указать файл с инклудами. Если я правильно понимаю, то тупо берется скажем 30 .h файлов, содержимое которых пихается в один. В итоге у тебя не 30 -I/longpath/1.h -I/longpath/2.h ... -I/longpath/30.h, а всего один -I/longpath/tmp/allinone.tmp
Но они не учли, что подобной проблемы в MSYS нет и пытаются тупо через "win32:" навязать подобный метод компиляции используя команды и пути cmd, а не bash. В итоге я отредактировал makefile'ы и убрал эти инклюды в 24-х местах. Я пока не знаю как себя поведет компилятор, но пока собирается. И совершенно не представляю как у меня собралось в первый раз всё, когда я просто набрал make еще раз. Т.е. для пользователей cmd проблемы быть не должно. |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 26.4.2024, 16:44 |