2011-07-12 2 views
1

Наш проект Qt 4.5 имеет корневой файл .pro с переменной SUBDIRS qmake. Когда qmake вызывается в этом корневом файле .pro, он генерирует Makefile, который вызывает «qmake & & make» для каждой вспомогательной директории.Улучшение производительности Makefile, созданного с помощью qmake

Теперь проблема заключается в том, что для более 100 вспомогательных папок это занимает много времени для изменения одного линейного файла другого мудрого обновленного проекта, который будет обнаружен. (Требуется около 13 секунд, waaay дольше.) Запуск make в корне проекта сначала меняет каталог на все поддиректории и запускает ничего не делать, пока не найдет тот каталог, в котором он действительно должен работать. (Работа в настоящий момент заключается в том, чтобы вручную записать компакт-диск в папку, в которой вы знаете, что вы внесли изменения в код, и просто запустите make. Для нашей среды eclipse это неудобно.)

В идеале только файл .pro для root. должен быть изменен, но я буду принимать ответы, которые также обрабатывают файл Makefile.

Любые предложения по сокращению тривиального времени выполнения будут оценены.

ответ

2

Это классический аргумент в пользу теории recursive make considered harmful: Ваша проблема в том, что у вас есть десятки одиночных Make-файлов вместо одного большого. Единственный путь вокруг затруднительного положения состоит в том, чтобы рефакторировать файлы .pro так, чтобы генерировался только один Makefile. Я не знаю достаточно о qmake, чтобы рассказать вам, как это сделать, хотя, извините.

+1

Проблема с рекурсивным make НЕ является тем фактом, что у вас много Make-файлов, но тот факт, что при создании этих многих make-файлов вы неправильно устанавливаете зависимости файлов. То есть, поскольку вы (qmake) боитесь потерять зависимость, она ставит больше зависимостей, которые необходимы. Следовательно, make занимает слишком много времени, потому что он делает ненужные файлы. – Shahbaz

+0

Если вы правильно пишете рекурсивные файлы Makefile, они имеют такую ​​же производительность, как ваш предложенный метод. Это включает в себя, однако, много ручного указания, какой файл имеет зависимости, которые могут стать громоздкими, но это еще одна проблема. – Shahbaz

+0

@Shahbaz: Питер Миллер заявляет в связанной статье (и, как мне кажется, делает сильный аргумент), что дополнительный повторный анализ дерева зависимостей для каждого вызова под-make является значительным фактором во время выполнения прогонов. И я думаю, что OP отметил в своих сообщениях, что запуск суперплоского компилятора, похоже, не является его проблемами, а скорее «делать ничего не делает». – thiton

Смежные вопросы