Russian Qt Forum
Ноябрь 02, 2024, 02:30 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 ... 3 4 [5] 6   Вниз
  Печать  
Автор Тема: В разных IDE разные файлы проектов...  (Прочитано 46245 раз)
SABROG
Гость
« Ответ #60 : Январь 05, 2010, 23:10 »

grep - никсовая команда, ищущая строку в файле... в 1м мейкфайле нет строк, содержащих broken.h (та где нет инклюда в мейне), во 2м есть. как следствие, qmake смотрит исходники

Это я знаю. Я подумал, что у тебя qmake генерит такой makefile, который grep'ом каждый раз выцепляет зависимости из исходников при вызове make. В общем какое твое мнение, баг или фича?
Записан
Dendy
Гость
« Ответ #61 : Январь 05, 2010, 23:18 »

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

Это делается только если явно выполнить qmake перед make. Речь же шла об автоматизации этого процесса.

Тем более что по вашим словам смейк выполняет ту же работу, но каждый раз и все нарекания на кумейк в скорости

CMake делает это автоматически и быстро, поскольку не перегенерирует сам Makefile, а список зависимостей хранит в отдельных файлах: depend.internal и depend.make и перегенерирует их с помощью скрипта DependInfo.cmake, а не парсит файл проекта вновь и вновь.

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

И это только список зависимостей. Я уже не говорю про то, что в QMake напрочь отсутствует механизм проверки формата команды для генерации целей. И здесь вам уже никакой дополнительный вызов qmake перед make не поможет - только полная пересборка проекта, даже если вы изменили формат команды для одного файла из сотни.

Пример:

1. Два файла:

main.cpp
Код
C++ (Qt)
#include <stdio.h>
 
int main( int argc, char ** argv )
{
#ifdef BROKEN_YO
   printf( "Yo enabled\n" );
#else
   printf( "Yo disabled\n" );
#endif
   return 0;
}

broken.pro
Код
C++ (Qt)
CONFIG += console
SOURCES += main.cpp

$ qmake
$ make
$ broken
> Yo disabled

2. Добавляем макрос в pro-файл:

broken.pro
Код
C++ (Qt)
CONFIG += console
DEFINES += BROKEN_YO
SOURCES += main.cpp

$ qmake
$ make
$ broken
> Yo disabled

Смотрим содержимое Makefile - макрос дейстивтельно добавлен. Пересборка не произошла.

В CMake же хранится хеш со списком форматов команд для каждой цели в файле CMakeRuleHashes.txt, который автоматически пересоберёт именно тот файл, для которого вы добавили DEFINE. Всё это делается автоматом одним вызовом make. В QMake же эту головную боль лечат отрубанием головы:

$ make clean
$ make
$ broken
> Yo enabled
Записан
Авварон
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3260


Просмотр профиля
« Ответ #62 : Январь 05, 2010, 23:34 »

2 SABROG моё мнение - фича.
Другое дело, что кумейку не хватает функциональности и скорости.
Записан
SABROG
Гость
« Ответ #63 : Январь 05, 2010, 23:41 »

2 SABROG моё мнение - фича.
Другое дело, что кумейку не хватает функциональности и скорости.

Интересно, что придумают тролли http://labs.trolltech.com/blogs/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/
Записан
Dendy
Гость
« Ответ #64 : Январь 05, 2010, 23:44 »

Очевидно что Тролли знают про проблемы QMake'а. Другое дело что технически решить их практически нереально - нужно ломать архитектуру всей системы сборки. Поэтому называть багами не стали - ведь баги пришлось бы фиксить. Куда проще называть это фичей и переложить все проблемы на головы пользователей.
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #65 : Январь 06, 2010, 00:11 »

я кажется понял почему у части людей не возникает проблем, например, у меня.

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

Юра.
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #66 : Январь 06, 2010, 00:15 »

Dendy, насчёт внесения дефайнов в pro-файл ты прав. Я, чтобы сократить время пересборки, убиваю объектник который требуется пересоздать.
Записан

Юра.
Dendy
Гость
« Ответ #67 : Январь 06, 2010, 00:19 »

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

Этот фокус работает ровно один раз. Проинклудив заголовочник позже в другом cpp-файле зависимость этого cpp-файла от заголовочника не создастся. Со всеми вытекающими.
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #68 : Январь 06, 2010, 00:24 »

да, факт.
Записан

Юра.
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #69 : Январь 06, 2010, 01:26 »

Выходит qmake значительно слабее cmake, однако
Цитировать
Собственно вопрос стоял какой из генераторов Makefile'ов можно использовать для кодинга. QMake здесь однозначно сливает.
считаю это заявление преувеличением - мы используем у себя пока именно qmake и работать с ним вполне возможно. Хотя периодически возникают глюки которые решаются только перекомпиляцией всего проекта.
Записан
Dendy
Гость
« Ответ #70 : Январь 06, 2010, 02:08 »

Ну, можно и в ежовых рукавицах кодить. Вопрос в целесообразности. Назовите мне хоть хоть одно преимущество QMake перед CMake при инкрементальной сборке проекта.
Записан
lit-uriy
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 3880


Просмотр профиля WWW
« Ответ #71 : Январь 06, 2010, 02:29 »

>>при инкрементальной сборке проекта.
А ты по рабоче-крестьянски объясни, что это такое
Записан

Юра.
Dendy
Гость
« Ответ #72 : Январь 06, 2010, 02:55 »

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

P.S. Поискал в гугле "инкрементальная сборка", девятая ссылка - на мой пост в этом треде (-:
Записан
break
Гипер активный житель
*****
Offline Offline

Сообщений: 846


Просмотр профиля
« Ответ #73 : Январь 06, 2010, 03:15 »

Цитировать
Ну, можно и в ежовых рукавицах кодить. Вопрос в целесообразности. Назовите мне хоть хоть одно преимущество QMake перед CMake при инкрементальной сборке проекта.
Возможно преимуществ нет. Это просто наиболее простой не требующий затрат способ - т.к. сама Qt использует qmake - то логично что большинство проектов на Qt тоже используют qmake - возможно переход на cmake - это правильный шаг в развитие проекта.
Записан
Dendy
Гость
« Ответ #74 : Январь 06, 2010, 03:32 »

Приношу извинения break'у, которого ни за что зацепил гнилой овощ, летящий в сторону lit-uriy выше по треду (-: http://www.prog.org.ru/index.php?topic=11935.msg74788#msg74788
Записан
Страниц: 1 ... 3 4 [5] 6   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.103 секунд. Запросов: 23.