问题缘由
需要在将 Win 下 VS 编写的项目移植到 Linux 平台下,并用 QT 调试。
- 将项目源码通过
CMakeLists .txt
重新组织,并编译测试。 - 仿照
CMakeLists.txt
编写 QT 的.Pro
文件。 - 测试
OSG
的依赖库在.Pro
下的书写规则。
步骤 1 - CMake
- 以 OSG 源码 (3.7.0) 中的
examples/osganimate
为测试例子进行编译,首先编译好 OSG 自己的库,编译过程省略,这里认为编译好的库位于osg/build
中,后续将使用这一路径。 - 对
examples/osganimate
例子单独编写CMakeLists .txt
如下,这里利用了通配符,可以将全部的 OSG 库都链接上。
cmake_minimum_required(VERSION 3.10)
project(osganimate)
include_directories("xx/osg/build/include")
link_directories("xx/osg/build/lib")
file(GLOB OSG_LIBS "xx/osg/build/lib/libosg*")
add_executable(${PROJECT_NAME} osganimate.cpp)
target_link_libraries(${PROJECT_NAME} -lOpenThreads ${OSG_LIBS})
步骤 2 - QMake
- 新建 QT 的基于 QMake 的空项目,将
osganimate.cpp
拷贝到项目中,并添加现有文件,然后编写 .Pro 文件如下:
QT += core gui
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = osg_qt_test
SOURCES += \
osganimate.cpp
OSG_LIBS_PATH = xx/osg/build/lib/
DEPENDPATH += xx/osg/build/lib/
INCLUDEPATH += xx/osg/build/include
LIBS += \
-L $$OSG_LIBS_PATH -losgAnimation \
-L $$OSG_LIBS_PATH -losgDB \
-L $$OSG_LIBS_PATH -losgFX \
-L $$OSG_LIBS_PATH -losgGA \
-L $$OSG_LIBS_PATH -losgManipulator \
-L $$OSG_LIBS_PATH -losgParticle \
-L $$OSG_LIBS_PATH -losgPresentation\
-L $$OSG_LIBS_PATH -losgShadow \
-L $$OSG_LIBS_PATH -losgSim \
-L $$OSG_LIBS_PATH -losg \
-L $$OSG_LIBS_PATH -losgTerrain \
-L $$OSG_LIBS_PATH -losgText \
-L $$OSG_LIBS_PATH -losgUI \
-L $$OSG_LIBS_PATH -losgUtil \
-L $$OSG_LIBS_PATH -losgViewer \
-L $$OSG_LIBS_PATH -losgVolume \
-L $$OSG_LIBS_PATH -losgWidget \
-L $$OSG_LIBS_PATH -lOpenThreads
步骤 3 - 测试 Pro 书写规则
- 通过 QT 自己添加依赖库可以方便地生成跨平台和 Debug / Release 区分的依赖,但是麻烦在于需要逐个添加,可以添加一个后,在此基础上修改手动增添多个库。
- QT 的 Pro 文件貌似不太支持通配符的写法,这里可能是个人水平和时间有限,没有深究。
- 对于上面这样的一个简单的 OSG 例子,以上是极简的 .Pro 写法,为了探究什么是必须的模块,工程中需要写的再完善一些。
- 小结一下:QMake 和 CMake 的思路是类似的,无非是添加头文件路径和库路径,然后链接指定的库,上面测试了利用 QMake 构建 CMake 项目的流程,目前 OSG 和 QT 还没有深度结合,只是利用了 QT 的编译环境,即使复杂的任务,也脱离不了以上的基础概念。
结果
- 利用 QMake 编译生成的可执行文件,与 CMake 生成的无异。