代码之家  ›  专栏  ›  技术社区  ›  Wyatt Anderson

如何在Win32 C++应用程序中集成和打包这个第三方库?

  •  1
  • Wyatt Anderson  · 技术社区  · 15 年前

    我们有一个(非常大的)自定义ActiveX控件的现有代码库,并且我想集成 libkml 正确的 集成第三方库的方法是。谢天谢地, 确实提供了编译它的MSVCC项目,所以移植不是问题。我想我有几个选择可以考虑:

    1. . 我们已经为“main”项目提供了一个包含项目文件的解决方案;我可以添加 libkml语言 但我不想这么做。不太可能 代码将根据我们应用程序的代码更改。

    2. .lib libkml语言 . 这不好看,因为有六个 解决方案,并且在链接器选项中手动指定它们似乎不雅。

    3. 将代码打包为DLL

    4. 编写包装器代码来抽象我需要的功能,将其打包到一个COM DLL中,并与之交互 . 这个 似乎 我认为这是明智的,但是很难确定我需要多少抽象,因为我还没有编写将要使用的代码 但是。

    libkml语言 然而,这主要是实验性的。选项1和选项2也很复杂,因为 libkml语言 另外还依赖于另外三个外部库 .lib文件 文件(我必须重新编译以使代码生成标志对齐)。目标显然是让代码工作,但可维护性和源代码树组织也是目标,所以我倾向于选择3和4,但我不知道在Windows上实现这些目标的最佳方法。

    3 回复  |  直到 15 年前
        1
  •  1
  •   Hans Passant    15 年前

    键入六个文件名,或使用带有pragma comment(lib,“foo.lib”)的声明式样式,与将其转换为DLL或COM服务器所需做的工作相比,是微不足道的。

    发行版非常倾向于将其用作静态链接库。只有spotty声明可以将其转换为带有declspec(dllexport)的DLL。它们只存在于第三方依赖关系中。当然,所有这些都使用不同的定义,您将在项目的预处理器定义中键入一组名称。

    此外,由于在COM服务器中使用此DLL,因此在运行时实际加载此DLL将非常困难。当COM创建控件实例时,DLL的搜索路径将是客户端应用程序的路径,不太可能靠近部署DLL的位置。

    使其成为COM服务器是 许多

        2
  •  1
  •   Björn Pollex    15 年前

    您还可以将所需的所有功能打包到非COM dll中。Visual studio支持创建一个静态包装库,当链接时,它将使您的程序使用dll。这样,您只需要指定一个依赖项,而不是六个。

        3
  •  1
  •   Mark    15 年前

    也许我遗漏了一些东西,但我真的不知道(1)有什么问题。我认为,即使您有多个使用libkml的项目,只要将libkml的项目文件插入到解决方案文件中,指定依赖项,就应该完成。很简单。即使解决方案(2)也非常简单。如果库发生了变化,你就需要重新构建——无论如何你都需要这样做。

    我看不出(3)或(4)是多么必要,甚至是多么渴望。对我来说,这听起来像是为目标(源代码树组织和可维护性)做了很多工作,我甚至不确定这些选项是否真的能实现。事实上,你自己说过“libkml代码与我们应用程序的代码相比不太可能发生变化。”

    这些年来我发现的是保持简单。如果重建KML可能很耗时,请获取libs并静态链接到库。是的,还有其他的依赖项,但是您只需设置一次就可以完成,希望以后再也不用担心了。否则,就把它放在项目中,然后继续前进。我认为值得问的是,在这个问题上花很多时间是否值得麻烦。