上一章介绍了qtcanpool的工程管理,本章要介绍的是:如何使用好工程管理?
为了更好的使用工程管理,作者给出了两个工程模板,放在projects目录下:
在“工程管理”一文中,作者以应用fancydemo和库qcanpool为例,简要的介绍了如何使用工程管理,这里再看一下:
细心的读者可能会发现,这里面有很多demo和lib,这会带来什么问题呢?
一个demo就是一个应用(可执行程序),不同的demo会依赖不同的库,比如:fancydemo依赖qcanpool、fancyribbon依赖qcanpool、litedemo依赖qlite……
这些demo是作者为了演示qtcanpool提供的功能而精心准备的,那么如果用户想用qtcanpool来开发自己的项目,该怎么做呢?
【方法一】
参考现有的demo,建立自己的工程,然后链接需要的库,进行开发……
【方法二】
参考现有的demo,建立自己的工程,然后链接需要的库,把不相干的文件都从pro和磁盘中删除,然后进行开发……
可能读者对这些感受不深,因为可能没用过qtcanpool,或者用的不多。
作者之前都是采用的方法二,那时qtcanpool还没有开源,拷贝文件是常有的事,那时作者还不会用git,所以经常打包文件备份到云盘。
qtcanpool开源后,作者意识到这个问题可能会困扰到别人,所以想方设法地试图去解决这个问题,解决的办法就是“工程模板”。
什么是工程模板呢?我们先来看一下:
qtproject.pri、library.pri、qlite_dependencies.pri……这些不就是工程管理里面讲的核心配置文件吗?
对对对,但,是又不是:
下面,我们打开template.pro详细的看下这些文件到底是怎么回事。
!isEmpty(CONFIG_PRI_INCLUDED):error("config.pri already included")
CONFIG_PRI_INCLUDED = 1
isEmpty(QTPROJECT_VERSION): QTPROJECT_VERSION = 1.0.1
isEmpty(QTPROJECT_COMPAT_VERSION): QTPROJECT_COMPAT_VERSION = 1.0.1
isEmpty(QTPROJECT_DISPLAY_VERSION): QTPROJECT_DISPLAY_VERSION = 1.1.0-rc1
isEmpty(QTPROJECT_COPYRIGHT_YEAR): QTPROJECT_COPYRIGHT_YEAR = 2019
isEmpty(BINARY_ARTIFACTS_BRANCH): BINARY_ARTIFACTS_BRANCH = 1.1
isEmpty(QTPROJECT_DIR): QTPROJECT_DIR = $$PWD
isEmpty(QTPROJECT_OUT_PWD): QTPROJECT_OUT_PWD = $$OUT_PWD
isEmpty(QTPROJECT_PRO_FILE_PWD): QTPROJECT_PRO_FILE_PWD = $$_PRO_FILE_PWD_
isEmpty(QTPROJECT_PRO_FILE): QTPROJECT_PRO_FILE = $$_PRO_FILE_
isEmpty(QTCANPOOL_DIR): QTCANPOOL_DIR = $$quote($$PWD/../..)
前面是工程版本和工程目录的配置,最后一个 QTCANPOOL_DIR 比较关键,这个是配置QTCANPOOL的目录,配置之后,轻量化的qtproject.pri、library.pri就可以嫁接在工程管理的那些核心管理文件上了。
include(config.pri)
include($$QTCANPOOL_DIR/qtproject.pri)
嫁接qtcanpool的qtproject.pri。
include(../qtproject.pri)
TEMPLATE = subdirs
CONFIG += ordered
SUBDIRS += \
libs \
app
include(../../qtproject.pri)
TEMPLATE = subdirs
SUBDIRS = \
qlite
for(l, SUBDIRS) {
QTC_LIB_DEPENDS =
include($$l/$${l}_dependencies.pri)
lv = $${l}.depends
$$lv = $$QTC_LIB_DEPENDS
}
添加库qlite,并自动解析其依赖关系,这里的qlite是直接使用qtcanpool提供的qlite,用户可以在libs目录下开发自己的库,如果比较好的库,也可以贡献到qtcanpool中。
isEmpty(QTLIBRARY_PRO_FILE_PWD): QTLIBRARY_PRO_FILE_PWD = $$_PRO_FILE_PWD_
include(../config.pri)
include($$QTCANPOOL_DIR/src/library.pri)
嫁接qtcanpool的library.pri。
include(../../library.pri)
include($$QTCANPOOL_DIR/src/libs/qlite/qlite-lib.pri)
引用qtcanpool的qlite库。
QTC_LIB_NAME = qlite
定义qlite的库名字。
projects目录下有两个工程模板和一个应用案例。
目录 | 说明 |
---|---|
template | 模板1,应用程序+库的模式 |
template2 | 模板2,应用程序+库+插件的模式 |
qtcreator | 移植的qtcreator最小插件系统(coreplugin) |
上面的config.pri最后的 QTCANPOOL_DIR 是用来配置qtcanpool的目录的,目前工程模板都是在projects目录下,属于qtcanpool的子目录,所以模板里config.pri的QTCANPOOL_DIR都是配置的相对目录。
如果将QTCANPOOL_DIR配置成绝对路径,比如:D:\projects\qt\qtcanpool。那么,是不是意味着用户自己开发的项目将可以放到任一位置,不再受qtcanpool目录的约束,qtcanpool将作为共享的仓库,文件冗余是不是就可以解决了?
慢,这里是不是有点眼熟,在“工程管理”的演进章节的父目录一节中讲到的hello和hellocanpool,跟这里是不是一样?
额,那“编译过程麻烦、依赖关系弱……”的问题,是不是又出现了?
不会,这里的工程模板是嫁接在工程管理的核心文件上的,依赖自动解决,完美无瑕!
附上一个基于qtcanpool的项目:qads(Qt Advanced Docking System)
gitee地址:https://gitee.com/canopen/qads
后补:
Qt-Advanced-Docking-System较为官方地址:https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System
template2和qtcreator,感兴趣的可以自行解锁!
欢迎贡献自己优秀的库到qtcanpool中……