头文件C++模块之间的依赖关系

dim*_*mba 7 c++ dependencies development-environment

在我的位置,我们有一个很大的C++代码库,我认为如何使用头文件存在问题.

Visual Studio项目很多,但问题出在概念上并且与VS无关.每个项目都是一个模块,执行特定的功能.每个项目/模块都编译为库或二进制文件.每个项目都有一个包含所有源文件的目录 - *.cpp和*.h.一些头文件是模块的API(我的意思是声明创建的库的API的头文件子集),有些是内部的.

现在解决这个问题 - 当模块A需要使用模块B时,A会添加B的源目录以包含搜索路径.因此,A在编译时可以看到所有B的模块内部头.

作为副作用,开发人员不必强调每个模块的确切API,我认为这是一个坏习惯.

我首先考虑了它应该如何应用.我想在每个项目中创建一个仅包含接口头文件的专用目录.希望使用该模块的客户端模块仅允许包含接口目录.

这种方法可以吗?你的位置如何解决问题?

UPD在我以前的地方,开发是在Linux上用g ++/gmake完成的,我们确实用来将API头文件安装到一个公共目录,这是一些建议的答案.现在我们使用cmake生成项目文件的Windows(Visual Studio)/ Linux(g ++)项目.我如何强制在Visual Studio中预先安装API头文件?

谢谢德米特里

RC.*_*RC. 3

听起来你走在正确的轨道上。许多第三方库都做同样的事情。例如:

3rdParty/myLib/src/ - 包含编译库所需的标头和源文件
3rdParty/myLib/include/myLib/ - 包含外部应用程序包含所需的标头

有些人/项目只是将外部应用程序要包含的标头放在 /3rdParty/myLib/include 中,但添加额外的 myLib 目录可以帮助避免名称冲突。

假设您使用结构:3rdParty/myLib/include/myLib/

在外部应用程序的 Makefile 中:
----------------
包括 =-I$(3RD_PARTY_PATH)/myLib/include
INCLUDE+=-I$(3RD_PARTY_PATH)/myLib2/include
...
...

在外部应用程序的源/标头中
#include“myLib/base.h”
#include“myLib/object.h”

#include“myLib2/base.h”