我应该如何在 Win32 C++ 中集成并打包这个第三方库？应用程序？
我们有一个（非常大的）自定义 ActiveX 控件的现有代码库，我想集成 libkml 进入它是为了与 KML 映射数据交互，而不是重新发明轮子。问题是，我是一个相对较新的 Windows 开发人员，来自 Linux 世界，我真的不确定集成第三方库的正确方式是什么。值得庆幸的是，libkml 确实提供了用于编译它的 MSVCC 项目，因此移植不是问题。我想我有几个我能想到的选择：
直接构建并链接库。我们已经有了一个包含“主”项目的项目文件的解决方案；我可以将
libkml项目添加到该解决方案中，但我不想这样做。libkml代码相对于我们应用的代码不太可能发生变化。静态链接到
libkml构建生成的.lib文件。这没有吸引力，因为有六个.lib文件来自libkml解决方案，并且在链接器选项等中手动指定它们似乎不太优雅。将代码按原样打包在 DLL 中。也许用COM？看起来如果我在没有任何翻译的情况下执行此操作，我最终会产生大量开销，而且由于我对 COM 相当不熟悉，我不知道公开我的所有功能会涉及多少工作”我想通过 COM 使用。该库相当大，有很多使用的类，如果我必须手动编写代码来公开所有内容，我会犹豫是否要走这条路。
编写包装器代码来抽象我需要的功能，将其打包在 COM DLL 中，并与之交互。我认为这似乎是明智的，但很难确定我需要多少抽象，因为我还没有编写使用
libkml的代码。
让我重申一下：我还没有编写与 libkml 交互的代码，所以这主要是实验性的。选项 1 和 2 也很复杂，因为 libkml 另外还依赖于 .lib 文件中的另外三个外部库（无论如何我都必须重新编译它们才能获得代码生成标志要排队）。目标显然是让代码正常工作，但可维护性和源代码树组织也是目标，所以我倾向于选项 3 和 4，但我不知道在 Windows 上处理这些问题的最佳方法。
We have a (very large) existing codebase for a custom ActiveX control, and I'd like to integrate libkml into it for the sake of interacting with KML mapping data, rather than reinventing the wheel. The problem is, I'm a relatively new Windows developer, and coming from the Linux world, I'm really not sure what the right way of integrating a third party library is. Thankfully, libkml does provide MSVCC projects for compiling it, so porting isn't a problem. I guess I have a couple choices that I can think of:
Build and link the library directly. We already have a solution with project files in it for the "main" project; I could add the
libkmlprojects to that solution, but I'd rather not. It's very unlikely that thelibkmlcode will change in relation to our app's code.Statically link to the
.libfiles produced by thelibkmlbuild. This is unattractive, since there are six.libfiles that come out of thelibkmlsolution and it seems inelegant to manually specify them in the linker options, etc.Package the code as-is in a DLL. Maybe with COM? It seems like if I did this without any translation, I'd end up with a lot of overhead, and since I'm fairly unfamiliar with COM, I don't know how much work would be involved in exposing all the functionality I'd like to use via COM. The library is fairly big, has a lot of classes it uses, and if I had to manually write code to expose it all, I'd be hesitant to go this route.
Write wrapper code to to abstract the functionality I need, package that in a COM DLL, and interact with that. This seems sensible, I suppose, but it's difficult to determine how much abstraction I need since I haven't written the code that would use
libkmlyet.
Let me reiterate: I haven't yet written the code that will interact with libkml yet, so this is mostly experimental. Options 1 and 2 are also complicated by the fact that libkml relies additionally on three more external libraries that are also in .lib files (that I had to recompile anyways to get the code generation flags to line up). The goal obviously is to get the code to work, but maintainability and source tree organization are also goals, so I'm leaning towards options 3 and 4, but I don't know the best way to approach those on Windows.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与将其转换为 DLL 或 COM 服务器所需的工作相比，键入六个文件名或使用带有 #pragma comment(lib, "foo.lib") 的声明式样式是小菜一碟。
该发行版严重偏向于将其用作静态链接库。只有不稳定的声明可用于使用 __declspec(dllexport) 将其转换为 DLL。它们仅存在于第 3 方依赖项中。当然，所有这些都使用不同的#define，您将通过在项目的预处理器定义中键入一堆名称来实现。
此外，由于您在 COM 服务器中使用该 DLL，因此在运行时实际加载该 DLL 会很困难。当 COM 创建控件实例时，DLL 的搜索路径将是客户端应用程序的搜索路径，不可能靠近部署 DLL 的位置。
使其成为 COM 服务器是一项大量工作，您必须自己编写所有接口胶水。同样，源代码中没有任何内容可以帮助解决这个问题。
Typing six file names, or using the declarative style with #pragma comment(lib, "foo.lib") is small potatoes compared to the work you'll have to do to turn this into a DLL or COM server.
The distribution is heavily biased towards using this as a static link library. There are only spotty declarations available to turn this into a DLL with __declspec(dllexport). They exist only in the 3rd party dependencies. All using different #defines of course, you'll by typing a bunch of names in the preprocessor definitions for the projects.
Furthermore, you'll have a hard time actually getting this DLL loaded at runtime since you are using it in a COM server. The search path for DLLs will be the client app's when COM creates your control instance, not likely to be anywhere near close to the place you deployed the DLL.
Making it a COM server is a lot of work, you'll have to write all the interface glue yourself. Again, nothing already in the source code that helps with this at all.
您还可以将所需的所有功能包装在非 COM-dll 中。 Visual Studio 支持创建静态包装库，链接后将使您的程序使用 dll。这样，您只需指定一个依赖项，而不是六个。
除此之外，指定六个依赖项有什么问题。我认为有充分的理由认为它们是六个独立的库而不是一个，因此明智的做法是准确指定您实际使用的部分。
You can also wrap all the functionality you need in a non-COM-dll. Visual studio supports creating a static wrapper library which, when linked, will make your program use the dll. This way you only have one dependency to specify instead of six.
Other than that, what is wrong with specifying six dependencies. I would assume that there is a good reason that these are six separate libraries instead of one, so it is prudent to specify exactly which parts you actually use.
也许我在这里遗漏了一些东西，但我真的不明白（1）有什么问题。我认为即使您有多个使用 libkml 的项目，只需将 libkml 的项目文件插入到您的解决方案文件中，指定依赖项，就应该完成。这非常简单。即使解决方案（2）也非常简单。如果库发生变化，您就需要重建 - 无论如何您都需要这样做。
我不明白（3）或（4）如何是必要的或什至是期望的。对我来说，这听起来像是为了目标（源代码树组织和可维护性）做了大量工作，我什至不确定这些选项是否真正满足。事实上，您自己说过“libkml 代码相对于我们应用程序的代码不太可能发生改变。”
多年来我发现，要让事情变得简单。如果重建 KML 可能很耗时，请获取库并静态链接到库。是的，还有其他依赖项，但您只需设置一次即可完成，希望再也不用担心它。否则，将其保留在项目中并继续。我认为值得一问的是，在这个问题上花费大量时间是否值得。
Maybe I'm missing something here, but I really don't see what is wrong with (1). I think that even if you had multiple projects that were using libkml, just insert the project file for libkml into your solution file, specify the dependencies, and you should be done. It's dead simple. Even solution (2) is dead simple. If the libraries ever change, you rebuild - you're going to need to do that anyway.
I'm failing to see how (3) or (4) are necessary or even desired. To me, it sounds like a lot of work for goals (source tree organization and maintainability) that I'm not even sure that those options really meet. In fact, you said yourself that "It's very unlikely that the libkml code will change in relation to our app's code."
What I've found over the years is to just keep things simple. If rebuilding KML is potentially time consuming, grab the libs and just statically link to the libraries. Yes, there are other dependencies, but you'll set this up once and be done, hopefully never to worry about it again. Otherwise, stick it in the project and move on. I think that it's worthwhile to ask whether spending a lot of time on this issue is worth the trouble.