相信大家很多和我一样,用多了微软给的便利,用人家的就十分不习惯.于是就琢磨原来用到的功能现在要整顺手来,不然可让人怎么活啊! 本篇主要介绍实践使用,并非一篇完整教程,有待读者补充.^_^
我们原本在VS上有一个大工程sln,里面有lib,有dll有exe,甚至还混搭了C#.用起来一点不觉得水土不服.现在要用QT重整,并且需要处处考虑换个平台不要让我改东西.作为探路先锋,先挑了几个基础工程出来做实验:
↑当然,图中是已经成事之后了.想在qtcreator中弄一个工程集还真不是那么方便,我到处找过了,压根没有创建工程集的办法.纵使你可以一个pro一个pro的拖进去,最后也没法保存,下次打开还得重新一个一个pro的拖,没哪个傻蛋总这么干吧..所以首先就是要手动创建一个subdirs型的pro做为工程集,也就是上面看到的
**CloudBoard_win32.pro**(subdirs举例)
TEMPLATE = subdirs
SUBDIRS =\
raknet\
onetengine \
omisc \
testDebugShow
onetengine.depends = raknet omisc
testDebugShow.depends = omisc
#CONFIG += ordered
关于这个pro的详细写法,感觉qt文档写的很细碎,反正我是没看明白.就着广大网友的例子才有了上面一段.TEMPLATE=subdirs这是固定写法,声明是做工程集目录的.SUBDIRS是指明目录中有哪些项,可以嵌套另一个subdirs型的pro. 接下来可以详细定义其中的项目.如.depends表示左边的依赖=后面的项目.
.subdir |
指定子项的目录,不使用子项本身的名字. |
.file |
明确指定该子项使用的pro文件,默认是根据名字自动找的,该项不和.subdir同时使用 |
.condition |
Specifies a bld.inf define that must be true for subproject to be built. Available only on Symbian platform. |
.depends |
该子项依赖指定的子项,只在使用makefiles的平台有效 |
.makefile |
该子项的makefile,只在使用makefiles的平台有效 |
.target |
该子项的TARGET,只在使用makefiles的平台有效 |
**omisc.pro**(staticlib举例)
QT -= gui ①
TARGET = misc ②
TEMPLATE = lib #固定写法
CONFIG += staticlib #静态库固定写法
#DEFINES += ③
DESTDIR = $$_PRO_FILE_PWD_/../lib ④
SOURCES += \
ostatic.cpp \
odebugoutput.cpp
HEADERS += omisc.h \
ostatic.h \
ostringmap.hpp \
odebugoutput.h
unix:!symbian { ⑤
maemo5 {
target.path = /opt/usr/lib
} else {
target.path = /usr/lib
}
INSTALLS += target
}
⑤最后这段是自动产生的,本人实在没有仔细研究,看样子应该是一种指定target目录的办法.而unix:!symbian让人不难想到,这是在筛选特定平台.具体的欢迎您测试后补充^_^
raknet相信很多童鞋了解,本案简单将其代码编译成staticlib,DESTDIR=$$_PRO_FILE_PWD_/../lib完工
**onetengine.pro**(动态库举例)
include( ../common.pri ) { ①
error(" Couldn't find the common.pri file! ")
}
QT -= gui
QT += network xml
TARGET = netengine
TEMPLATE = lib
DESTDIR = ../bin #基于生成目录
INCLUDEPATH += ../omisc ../raknet/source ②
DEPENDPATH += ../omisc ../raknet/source #基于工程目录
win32:LIBS += -lWs2_32 ③
LIBS += -lmisc -lraknet
DEFINES += ONETENGINE_LIBRARY ④
SOURCES += onetengine.cpp \
netengine_export.cpp
HEADERS += onetengine.h\
onetengine_global.h \
../include/macrodefine.h \
../interface/isinkfornetengine.h \
../interface/inetengine.h
**common.pri**(pro包含举例)
INCLUDEPATH += ../interface ../include ⑤
#LIBS += -L$$QTDIR/lib
LIBS += -L../../src/lib
LIBS += -L../lib
**common.pri**(pro包含举例)
INCLUDEPATH += ../interface ../include ⑤
#LIBS += -L$$QTDIR/lib
LIBS += -L../../src/lib
LIBS += -L../lib
①没错,pro中也是可以include的,以当前文件为起点将上一层的common.pri包含进来.common.pri中的相对路径依然以当前pro路径为基础.
②INCLUDEPATH是包含目录,类似于VS中的附加包含目录.至于 DEPENDPATH本人实事求是没有研究不明白有什么用.欢迎补充^_^③使用筛选器,仅在win32下增加Ws2_32.lib的导入. LIBS相当于VS中的附加依赖库,不同的是可以通过-L指定库目录,-l指定库名.其间没有空格的哦.例如上面的LIBS+=-L../lib -lmisc就是可以到../lib中找misc库.misc没有说明.a还是.lib是让qt帮我们做.你也可以指定.lib,然后通过筛选器把其他平台的也写一下.
④提供宏定义ONETENGINE_LIBRARY是因为在向导创建动态库的时候qtcreator帮我们定义了这样的
#ifndef ONETENGINE_GLOBAL_H
#define ONETENGINE_GLOBAL_H
#include
#if defined(ONETENGINE_LIBRARY)
# define ONETENGINESHARED_EXPORT Q_DECL_EXPORT
#else
# define ONETENGINESHARED_EXPORT Q_DECL_IMPORT
#endif
#endif // ONETENGINE_GLOBAL_H
提供宏定义ONETENGINE_LIBRARY决定了该工程的作用是导出动态库的.
⑤最后common.pri只是定义了几项公共的没有平台差异的信息
好了,testDebugShow的工程pro就不多说了,它和动态库的很相似,只有TEMPLATE=app没有XXXX_LIBRARY的宏定义而已.
最后补充一点,为什么总的工程名要叫CloudBoard_win32呢,明眼人一看就知道这是要分平台了呢.没错,一开始我也觉得一个pro就搞定了,里面可以有筛选器,一份pro足以应付.但是实际是qtcreator会为pro产生同名的.user文件,qtcreator的一些配置会写在.user里面,例如最关键的qtSDK位置,编译工具,构建/生成设置等.这些必须根据生成所处的环境区别设置. 所以当你原样跑到Linux下,启动pro就会告诉你配置是别处读来的,是否使用?是:配置一定是错的,否:配置被清洗.这都不是我们希望的.所以唯有分平台建总pro了.