多年来,我的项目使用越来越多的外部库,我这样做的方式开始变得越来越尴尬(尽管如此,必须说,它确实可以完美地工作)。我在Windows上使用VS,在其他人上使用CMake,在Windows上使用CodeComposer来定位数字信号处理器(DSP)。除了DSP之外,还使用了32位和64位平台。
以下是我现在正在做的事情的样本;请注意,如图所示,不同的外部库本身并不总是以相同的方式组织。一些有不同的lib / include / src文件夹,其他有一个src文件夹。有些已准备好使用静态和/或共享库,其他已构建
/path/to/projects
/projectA
/projectB
/path/to/apis
/apiA
/src
/include
/lib
/apiB
/include
/i386/lib
/amd64/lib
/path/to/otherapis
/apiC
/src
/path/to/sharedlibs
/apiA_x86.lib -->some libs were built in all possible configurations
/apiA_x86d.lib
/apiA_x64.lib
/apiA_x64d.lib
/apiA_static_x86.lib
/apiB.lib -->other libs have just one import library
/path/to/dlls -->most of this directory also gets distributed to clients
/apiA_x86.dll and it's in the PATH
/apiB.dll
每次添加外部库时,我大致都会使用此过程:
特别是第4步和第5步困扰着我。我很确定我不是唯一一个面临这个问题的人,并希望看到别人如何处理这个问题。
我正在考虑去掉每个库的环境变量,只使用一个'API_INCLUDE_DIR'并以有组织的方式用include文件填充它:
/path/to/api/include
/apiA
/apiB
/apiC
这样我就不需要在propertysheets中使用include路径,也不需要环境变量。对于仅在Windows上使用的库,我甚至根本不需要属性表,因为我可以使用#pragmas来指示链接器链接到哪个库。 同样在代码中,将更清楚包含的内容,并且不需要包装器包含具有相同名称但来自不同库的文件:
#include <apiA/header.h>
#include <apiB/header.h>
#include <apiC_version1/header.h>
退出当然是我必须复制包含文件,并且可能**在文件系统上引入重复项,但这看起来是一个很小的代价,不是吗?
**实际上一旦构建了库,我唯一需要的就是包含文件和你的库。由于每个都有一个专用目录,因此不再需要原始源树,因此可以删除..
答案 0 :(得分:1)
为什么不使用文件系统链接?
ln -s /path/to/apis/apiA/include /path/to/api/include/apiA
VOILÀ。类似的可以在Windows上完成,但我现在没有方便的命令行。