Управление структурой проекта (.pro)

[Apktyc]

Здравствуйте.

В этой теме хотелось бы обсудить, как Вы справляетесь с упорядочиванием своего проекта, придерживаетесь какой-либо структуры или нет. Может быть в каталоге проекта у Вас твориться творческий беспорядок, где все (от исходников и объектных файлов, до ресурсов и исполняемых) свалено в корневом каталоге, или наоборот везде царит строгий порядок, как в этой статье Структура Qt-проекта на C++?

Я никогда не пользовался теневой сборкой, вместо этого у меня в каталоге проекта есть каталог !prototype, куда и складываются бинарники.

Код:

win32:{
DESTDIR = "!prototype/Win32/$$TARGET"
}
PRECOMPILED_DIR = $$DESTDIR

Установка PRECOMPILED_DIR избавляет от появления раздражающих папок debug и release в корневом каталоге проекта.

Всю промежуточную генерацию загоняю в отдельный каталог.

Код:

OBJECTS_DIR = ".build/.obj"
MOC_DIR = ".build/.moc"
RCC_DIR = ".build/.rcc"

Исходники мирно свалены в каталоге "source".

Интересно было бы узнать, как это устроено у Вас.
Ну и вопрос по теме, есть ли возможность также структурировать сборку под Android, а то по-умолчанию все крутится в каталоге android-build.

[Racheengel]

Имхо это главная беда практически всех существующих систем сборок - ад конфигураций
Идеально бы было не иметь возможности вообще никак не влиять на "теневой" процесс, а применять паттерн Convention over Configuration.
То есть разработчика не должно заботить, как и в каком виде будут свалены промежуточные результаты.
Есть папка src, а далее есть папки bin и lib для каждого из поддерживаемых таргетов.
Вы, как разработчик, говорите только, ЧТО вы хотите собрать, а не КАК и КУДА.
Все правила и структура папок - четко предопределены системой сборки, шаг влево-вправо невозможен.
Зависимости - опять же есть глобальный каталог всего, что имеется в распоряжении, в четко предопределенном формате.
Вы указываете что то типа DEPENDS: qwt-6.2.1 (если версия принципиальна), или просто qwt, если не особо. Либо вообще ничего не указываете, и тогда система пытается найти все нужные либы автоматом.
Но это в идеале. А в реале я стараюсь по минимуму загружать pro-файлы (имя таргета, список исходников, ресурсы, инклуды с либами). Теневая сборка? Ну будет теневая. Пусть qmake с креатором думают, куда и шо им положить. Не принципиально.

[ssoft]

Стройная структура - признак хорошего проекта.
В случае работы над комплексом с большим количеством модулей без стройной структуры не обойтись.
В качестве примера выкладываю разработанное в том числе и мной решение.
Рассматривается комплекс, состоящий из множества компонентов, упорядоченных в произвольной иерархической структуре.

Проектные файлы комплекса:

- файл общей конфигурации config.prf, содержащий только информацию о том, куда и как собирать, и ничего, что относилось бы к компонентам.
- файл depends_path.prf, содержащий либо ручной перечень директорий для поиска компонентов, либо процедуру их автоматического поиска в поддиректориях.
- файл depends_resolver.prf со стандартным содержимым, обеспечивающий автоматическое разрешение зависимостей между компонентами.
- (опционально) другие файлы по желанию

Проектные файлы компонента:

- файл проекта <component>.pro, содержащий перечень исходных фалов и особенности сборки, не влияющие на зависимые компоненты.
- файл config_finder.prf с функцией автоматического поиска общей конфигурации системы (место поиска и наименование файла конфигурации определено здесь и может быть изменено/дополнено при необходимости).
- файл depends.prf (обязателен только для библиотек - компонентов, от которых могут зависеть другие компоненты), содержащий перечень зависимостей и особенности сборки, влияющие на зависимые компоненты.
- (опционально) файл files.prf со стандартным содержимым, позволяющий автоматически добавлять исходные файлы из конкретных директорий (includeFilesFrom) или из директорий и их поддиректорий (includeFiles).
- (опционально) другие файлы по желанию (напимер, файл предкомпилируемого заголовка)

Последовательность операций для qmake следующая:

* анализ проектного файла компонента <component>.pro
** определение типа компонента (lib, app, ...)
** определение особенностей сборки компонента (CONFIG, PRECOMPILED, win32, linux ...), не влияющих на зависимые компоненты
** включение локального файла config_finder.prf для автоматического поиска и включения общей конфигурации комплекса
*** включение файла общей конфигурации комплекса config.prf
*** определение способа, места сборки и расположения генерируемых файлов (CONFIG, DESTDIR, ...)
*** включение файла depends_resolver.prf автоматического разрешения зависимостей между компонентами
**** включение файла depends_path.prf с явным перечнем путей поиска зависимостей или (опционально) процедурой их автоматического определения
**** включение файлов depends.prf с зависимостями конкретных компонентов
***** определение зависимостей библиотек и заголовочных файлов (LIBS, INCLUDEPATH, DEPENDPATH)
***** определение особенностей сборки компонента (CONFIG, win32, linux ...), влияющих на зависимые компоненты
***** определение зависимостей от компонентов Qt (QT).
***** определение зависимостей компонентов комплекса (DEPENDS)
** (опционально) включение локального файла files.prf для возможности автоматического включения исходников
** явное/ручное (через INCLUDES, SOURCES, ...) или автоматическое (через includeFiles, includeFilesFrom ) включение исходников и других файлов