库依赖关系C++项目

-1

我一直在为此挣扎了很长一段时间，现在我真的需要弄清楚这一点。问题很简单。我有一个库L，依赖于另一个库D，然后我想为我的项目使用库L。问题是，当我包括L的头我得到（自然？）错误“无法打开包含文件是D的一部分”。库依赖关系C++项目

如果我正在写一个需要使用的项目L我不想关心它的依赖关系。一个实际的例子是一个包装多个图形API的“渲染框架”。用户不想为正确的操作系统包含正确的标题，因为这是图书馆的义务！

我真的很希望我明确自己，如果这个问题已经得到解答（我敢打赌它），请给我一些关键字来搜索？

感谢您对您的时间&编码快乐:)

对不起！你不能每个人都想'关心它的依赖关系'。要解决包含路径依赖关系，例如GCC的'-I'选项可以解决库路径依赖问题，链接器有'-L'选项。 –

如果L的标题需要D的标题，那么你需要D的标题来使用L. Period。故事结局。你能修改L库吗？如果是这样，有可能使L的标题不依赖于Ds标题... –

@πάνταῥεῖ如果他可以和我们所有人都错了怎么办？ :-D – 2014-02-20 04:08:55

链接L静态到你的“渲染架构”我建议你从IMB帮助阅读：When to use dynamic linking and static linking

当你建立L作为静态库，你可以“在你的可执行文件中包含“it”。所以，你不必关心L的位置。这有一些缺点，例如：如果你想改变属于L的儿子一段代码，你将不得不重新编译你所有的“渲染框架”。

表示：

实施顶库L。使用一些静态库（例如D）。并将中的所有*.h文件包含在您希望用户使用的文件中。

Boost库使用此模式进行代码组织。

2014-02-19 22:37:02

也许我没有得到它:(问题的关键是：如果我有一个示例应用程序，使用渲染框架，我不'我想要手动包含Direct3D或OpenGl，我希望框架能够做到这一点，并且框架将通过#pragma注释来关联库。这是一种糟糕的方法吗？ –

嗯，我不喜欢指向SO以外的来源的链接，除非这些指向某些“官方”标准出版物。即使如此，我宁愿在这里引用他们。 –

好吧，我得到你想说的，但是如果我在“L”中包含一个头“D”，然后在我的示例应用程序中包含“L”，我会收到错误（自然？）“丢失”D“ ”。有什么办法可以避免这种情况？我确实包含了来自“L”的头文件 –

[I]网络有一个使用的渲染架构我不想一个示例应用程序手动包括的Direct3D或OpenGL [...]

如果你的渲染架构已正确安装，其像OpenGL这样的依赖关系也必须正确安装。在这种情况下，框架的头文件应该在他们所期望的位置找到依赖项的头文件。

2014-02-19 23:23:43 markgz

回答