разделение исходников по подпроектам pri для многократного использования

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

Речь не идет исключительно о библиотеках, речь идет об исходном коде.

Разделение на библиотеки идет на основе pro файлов, разделение на модули исходного кода идет на основании pri файлов.

Допустим надо разделять исходный код на модули (pri) и потом удобным образом подключать в свой проект.

Тут надо сразу сказать о заголовочных файлах. Их лучше подключать в своих *.h файлах с указанием каталога, где они хранятся. То есть таким образом:

#include "my_wmi/wmi.h"

Это хоть значительно защитит от возможных конфликтов с другими дублирующими названиями wmi возможно из других подключаемых исходников.

Подключение модулей исходников через *.pri файл. То есть например в вашем *.pro ( или *.pri) файле проекта добавляем include :

include(my_wmi/wmi.pri)

При этом каталог my_wmi НЕ обязательно находится в каталоге вашего проекта, он может находится в любом месте файловой системы, например в каталоге ../my_libs/.

Чтобы все собралось нормально вам в файле pro ваше проекта надо подключить только путь к my_libs таким образом:

INCLUDEPATH += blablabla/my_libs
DEPENDPATH += blablabla/my_libs

INCLUDEPATH чтобы указать, где дополнительно искать my_wmi/wmi.h.
DEPENDPATH чтобы указать где дополнительно искать например ui формы

Но это не все. Если есть еще один важный момент. Теперь вы можете весь подключаемый и многократно используемый функционал разместить в подкаталогах каталога my_libs. И это реально удобно.

Далее можно добавить другой подпроект в pro вашего проекта , например :

include(mu_gui/gui.pri)

mu_gui находится тоже в my_libs. Это реально удобно.

В *.pri файлах надо обратить внимание на путь к исходникам типа *.cpp и *.h. А именно надо пути задавать просто верхний каталог и файл:

my_gui/my_gui.cpp

Имеется ввиду, что если добавлять в pri файл существующий файлы, то Qt Creator добавляет путь в таком виде:

../my_lib/my_gui/my_gui.cpp

И это лучше исправить.

Прикольный нюанс насчет содержания подкаталога отделенного функционала (типа my_gui/gui.pri) . Если в этом каталоге есть main.c файл по каким-то причинам, то каким-то образом ваш проект при сборке может подцепить main(..) функцию из не вашего main.c файла а понятно теперь из какого.

Таким образом для тестирования отделенного функционала (например my_gui/gui.pri) не надо в этото же каталог пихать main.c и др., лучше создавать отдельный каталог для тестирования с файлами main.c и т.д.

Теперь по-поводу наименований каталогов и файлов : наверное лучше не использовать заглавные буквы.

Теперь вопрос о вложенности отделенных проектов. Например есть kkt подпроект с базовым для кассовых аппаратов функционалом (абстракный класс) и есть внутри kkt подпроекты mercury и atol (реализации протоколов конкретных моделей кассовых аппаратов).

Чтобы подключить в свой проект все кассовые аппараты делаем в своем pro файле следующее:

INCLUDEPATH += ../kkt
DEPENDPATH += ../kkt

И видим, что они все появляются в дереве проектов:

фотка 1

Содержание файла kkt.pri:

HEADERS += \
    kkt/abstract_kkt.h

SOURCES += \
    kkt/abstract_kkt.cpp

include(mercury/kkt_mercury_wgt.pri)
include(atol/kkt_atol_wgt.pri)

Содержание файла kkt_mercury_wgt.pri:

HEADERS += \
    mercury/kkt_mercury_wgt.h \
    mercury/inecrman.h

SOURCES += \
    mercury/kkt_mercury_wgt.cpp \
    mercury/inecrman.cpp

FORMS += \
    mercury/kkt_mercury_wgt.ui

И все ккт, подключены к сборке, что очень удобно.

Разделяем проект на подпроекты.