我应该如何与Win32 C ++应用程序集成并打包第三方库?

我们有一个(非常大的)现有的ActiveX控件的代码库,为了与KML映射数据交互,我想集成libkml ,而不是重新发明轮子。 问题是,我是一个相对较新的Windows开发人员,来自Linux世界,我真的不确定集成第三方库的正确方法是什么。 谢天谢地, libkml提供MSVCC编译项目,所以移植不成问题。 我想我有一些我可以想到的select:

  1. 直接build立和链接库 。 我们已经有了一个解决项目文件的“主”项目; 我可以将libkml项目添加到该解决scheme,但我宁愿不。 libkml代码不太可能会根据我们应用程序的代码而改变。

  2. 静态链接到由libkml生成的.lib文件 。 这是没有吸引力的,因为libkml解决scheme中有六个.lib文件,并且在链接器选项中手动指定它们似乎是libkml

  3. 将代码按原样包装在一个DLL中 。 也许与COM? 看来如果我这样做没有任何翻译,我最终会有很多开销,因为我对COM很不熟悉,所以我不知道在展示所有的function时会涉及多less工作,喜欢通过COM使用。 图书馆是相当大的,有很多类使用,如果我不得不手动编写代码来暴露这一切,我会犹豫要走这条路线。

  4. 编写包装代码来抽象我需要的function,将其打包到一个COM DLL中,并与之交互 。 我想这似乎是合理的,但是我很难确定需要多less抽象,因为我还没有编写使用libkml的代码。

让我重申:我还没有编写与libkml交互的代码,所以这主要是实验性的。 选项1和2也是复杂的事实, libkml额外依赖于另外三个外部库也在.lib文件(我不得不重新编译以获得代码生成标志排列)。 目标显然是让代码工作,但可维护性和源树组织也是目标,所以我倾向于选项3和4,但我不知道在Windows上接近这些选项的最佳方法。

键入六个文件名,或者使用#pragma comment(lib,“foo.lib”)的声明式样式,与将其转换成DLL或COM服务器所需的工作相比,是小土豆。

这个分布严重偏向于将其用作静态链接库。 只有不明确的声明可以用__declspec(dllexport)把它变成一个DLL。 它们只存在于第三方依赖关系中。 当然,所有使用不同的#define,您将通过在项目的预处理器定义中键入一堆名称。

而且,由于您正在COM服务器中使用它,实际上在运行时会加载该DLL,所以很难实现。 当COM创建你的控件实例时,DLL的搜索路径将是客户端应用程序,不可能靠近你部署DLL的地方。

使它成为一个COM服务器是很多工作,你将不得不自己写所有的接口粘合剂。 同样,源代码中没有任何东西可以帮助完成这个任务。

您也可以将所需的所有功能包装在非COM-dll中。 Visual Studio支持创建一个静态的包装库,当链接时,将使您的程序使用DL​​L。 这样你只有一个依赖项来指定而不是六个。

除此之外,指定六个依赖关系有什么问题。 我认为有一个很好的理由,那就是六个独立的库,而不是一个,所以谨慎地指定你实际使用的是哪个部分。

也许我在这里错过了一些东西,但是我真的没有看到(1)有什么问题。 我认为,即使您有多个使用libkml的项目,只需将libkml的项目文件插入到您的解决方案文件中,指定依赖关系,即可完成。 这很简单 即使解决方案(2)也很简单。 如果图书馆改变了,你重建 – 无论如何你都需要这样做。

我没有看到(3)或(4)是必要的甚至是需要的。 对我来说,这听起来像是很多目标(源代码树组织和可维护性)的工作,我甚至不确定这些选项是否真的符合。 事实上,你自己说过:“libkml代码与我们应用程序的代码相关的可能性不大。”

我多年来发现的就是保持简单。 如果重建KML可能会耗费时间,请抓取库并静态链接到库。 是的,还有其他的依赖关系,但是你会设置一次并完成,希望不要再担心它。 否则,坚持在项目中继续前进。 我认为有必要问一下在这个问题上花费很多时间是否值得遇到麻烦。