Можно ли сделать так, чтобы QtCreator не анализировал часть pro файла?

[ssoft]

Для ведения проектов с помощью qmake разработана небольшая библиотека дополнительных фитч для qmake. Простой пример использования можно посмотреть здесь.

Некоторые из этих фитч, предполагают сбор информации о проекте - версия репозитория, зависимости между компонентами, генерация дополнительного кода. Во время загрузки проекта в QtCreator происходит разбор проектных файлов с помощью qmake, и функциональность этих фитч занимает достаточно ощутимое время (когда в проекте ~100 модулей и больше) и это немного раздражает)). К тому же на этапе анализа проекта эта функциональность не привносит никакой пользы, она нужна только на этапе сборки (точнее, на этапе выполнения qmake перед сборкой).

Можно ли сделать так, чтобы QtCreator не анализировал часть проектного файла при его загрузке?

[qate]

из описания непонятно - чем эти фичи полезны ?

[ssoft]

из описания непонятно - чем эти фичи полезны ?

Предполагается, что пользователи qmake знают, что это такое qmake features и чем они полезны).

Фитчи qmake - это относительно гибкий инструмент для расширения и настройки qmake под свои нужды. Здесь хорошо расписано http://blog.mgsxx.com/?p=1891.

Конкретно этот набор фитч мне удобен для организации разных проектов (комплексов), использующих одни и те же программные модули (компонентов).
Однотипное ведение проектных файлов позволяет быстро организовывать комплекс, состоящий из десятков и даже сотен компонентов.
Когда однотипное описание проектных файлов систематизировано и выделено в отдельные фитчи, в проектные файлы модулей сводятся к набору нескольких строк.

На вскидку, польза в этом:

1. Как правило, проектный файл компонента выглядит так, если это библиотека,

Код

TEMPLATE = lib
 
!load( include_files ) : error( Can not find feature \"include_files\" )
includeFiles( $${PWD}/../../src )
 

с файлом зависимостей

Код

LIBS *= -lmodule
 
INCLUDEPATH *= \
    $${PWD}/include \
 
DEPENDPATH *= \
    $${PWD}/include \
 
QT *= \
    core \
    gui \
 
DEPENDS *= \
    module2 \
    module3 \
 

или так, если это приложение,

Код

TEMPLATE = app
 
!load( include_files ) : error( Can not find feature \"include_files\" )
includeFiles( $${PWD}/../.. )
 
QT *= \
    core \
    gui \
    widgets \
 
DEPENDS *= \
    module \
 

Фитча include_files позволяет включить в проект все файлы из директории и ее поддиректорий (подобно cmake).
Фитча module_depends позволяет найти и применить все зависимости между модулями, определенными в переменной DEPENDS  (подобно cmake)

2. Сборка всех модулей происходит в единое место

Фитча complex_paths позволяет собирать модули одновременно разными комплектами в одном проекте независимо друг от друга.

3. Автоматический контроль версий.

Фитча auto_version формирует дополнительную информацию в модуле о текущей ревизии svn или git, дополняет приложения на Qt типовым диалогом "О программе" с информацией о версии и включенных модулях, их версиях и др.

4. Более внятный вывод сообщений

Фитча message_logging дополняет выводимые сообщения информацией о текущем проектном файле.

[ViTech]

Можно ли сделать так, чтобы QtCreator не анализировал часть проектного файла при его загрузке?

Если эти "ненужные" части закомментировать в .pro файле, проект будет нормально загружаться в QtCreator?

[ssoft]

Если эти "ненужные" части закомментировать в .pro файле, проект будет нормально загружаться в QtCreator?

Да). Эти части вызывают системные команды для получения информации git, svn, а также генерируют некоторые исходные файлы. В линуксе все происходит достаточно быстро, в винде подтормаживает.

[ViTech]

Тогда можно попробовать сделать так: в зависимости от каких-то внешних условий включать или отключать определённые части в .pro файлах. Внешним условием может быть определение/не определение переменной, которая передаётся параметром командной строки при вызове qmake. В QtCreator в Projects/Build Settings  создать отдельную build configurartion для "лёгкой" версии проекта, в Build Steps/Additional arguments передать определение переменной, например "SKIP_EXTRA_PHASE=TRUE". А в .pro файлах проверять, определена заданная переменная или нет, и, в зависимости от этого, что-то делать или не делать .

Код:

message("-----------")
message("Base phase.")

!defined(SKIP_EXTRA_PHASE, var) {
    message("Extra phase.")
}
message("-----------")

[ssoft]

Тогда можно попробовать сделать так: ...

Сделал). Эффект не такой, какой хотелось бы иметь. В этом случае с дополнительной переменной и проект анализируется, и сборка производится. Хотелось бы чтобы проект анализировался с одним набором переменных, а собирался с другим. Даже если настраивать для себя легковесную конфигурацию для разработки, для полноценной сборки все-равно придется переключаться в тяжеловесную. К тому же не всегда возможно донести этот подход до других пользователей), все хотят, чтобы всё работало "из коробки".

[ViTech]

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

"Другие пользователи" - это святое, нельзя допускать, чтобы они напрягались, особенно по всяким мелочам . Хотят "из коробки"? А пожалуйста!:
Qmake: Add special CONFIG variable "qtc_run" when parsing project files.

[ssoft]

Qmake: Add special CONFIG variable "qtc_run" when parsing project files.

Ура! Заработало!
Как хоть удалось найти? Даже по прямому поиску qtc_run поисковик ничего внятного не выдает).
Хотел уже было в исходные коды креатора лезть, но не успел).

[ViTech]

Ура! Заработало!
Как хоть удалось найти? Даже по прямому поиску qtc_run поисковик ничего внятного не выдает).
Хотел уже было в исходные коды креатора лезть, но не успел).

Среди других идей (добавить Custom Process Step, чтобы при сборке использовались другие переменные; определять родительский процесс) была изначально самая простая и очевидная, что уже есть какая-то переменная, которая определена при запуске в QtCreator. Только как она может называться и как её искать - х.з. . Решил ткнуть в самое простое: добавил message($$CONFIG) и посмотрел, что выводится при загрузке проекта в QtCreator и при сборке. Там эта qtc_run и засветилась, долго искать не пришлось . Хотя добавить её в документацию не помешало бы.