16

我有一个旨在创建一些 C++ 绑定的 Haskell 项目。我已经编写了 C 包装器并将它们编译成一个独立的静态链接库。

我想编写 Haskell 绑定以静态链接到 C 包装器，这样我就不必单独分发 C 包装器，但我似乎无法让它工作并希望得到一些帮助。

我将 C 库指定为额外库，但我的cabal build步骤似乎没有将其添加到编译命令中。

我创建了一个小项目来说明这一点（http://github.com/deech/CPlusPlusBindings）。

它包含一个小的 C++ 类 ( https://github.com/deech/CPlusPlusBindings/tree/master/cpp-src )、C 包装器 ( https://github.com/deech/CPlusPlusBindings/tree/master/c- src），一个有效的 C 测试例程（https://github.com/deech/CPlusPlusBindings/tree/master/c-test）和 Haskell 文件（https://github.com/deech/CPlusPlusBindings/blob/master/ src/BindingTest.chs）。

C 库是在 Setup.hs 中添加的，而不是在 Cabal 文件中，因为这就是我的真实项目的方式，它在构建步骤之前通过 Cabal 使用“make”构建 C 库。我已经验证在构建步骤中，该extraLibs部分BuildInfo包含库名称并extraLibDirs包含正确的目录。

我的输出cabal build是：

creating dist/setup
./dist/setup/setup build --verbose=2
creating dist/build
creating dist/build/autogen
Building CPlusPlusBinding-0.1.0.0...
Preprocessing library CPlusPlusBinding-0.1.0.0...
Building library...
creating dist/build
/usr/local/bin/ghc --make -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -I/home/deech/Old/Haskell/CPlusPlusBinding/c-src -I/home/deech/Old/Haskell/CPlusPlusBinding/cpp-includes -optP-include -optPdist/build/autogen/cabal_macros.h -package-name CPlusPlusBinding-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.6.0.1-8aa5d403c45ea59dcd2c39f123e27d57 -XHaskell98 -XForeignFunctionInterface BindingTest
Linking...
/usr/bin/ar -r dist/build/libHSCPlusPlusBinding-0.1.0.0.a dist/build/BindingTest.o
/usr/bin/ar: creating dist/build/libHSCPlusPlusBinding-0.1.0.0.a
/usr/bin/ld -x --hash-size=31 --reduce-memory-overheads -r -o dist/build/HSCPlusPlusBinding-0.1.0.0.o dist/build/BindingTest.o
In-place registering CPlusPlusBinding-0.1.0.0...
/usr/local/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace

不幸的是，编译和链接步骤都没有使用 C 库。没有其他警告或错误。

4

1 回答 1

12

为了解决这个问题，我不得不：

  1. 重新链接 Haskell 库与 C 绑定的目标文件和
  2. 使用我的Cabalghc-options文件中的标签来确保它们以正确的顺序链接。

所有更改都在测试项目（http://github.com/deech/CPlusPlusBindings）中。

下面详细解释了创建包含 C 和 Haskell 对象的新存档的过程，并不简单。之所以会出现这种复杂性，是因为（从 Cabal 1.16.0.2 开始）无法挂钩到构建过程的链接器部分。

在 Cabal 文件中设置标志是微不足道的，因此这里不再赘述。

重新链接 Haskell 库

  1. 通过添加以下内容将构建类型设置为custom：

    build-type: custom

    到阴谋集团文件。

  2. main通过将方法替换为插入自定义构建逻辑Setup.hs：

    main = defaultMainWithHooks simpleUserHooks {
              buildHook = myBuildHook, 
              ...
       }

    这告诉构建过程，与其使用其中定义的默认构建过程，simpleUserHooks不如使用myBuildHook下面定义的函数。同样，清理过程被自定义函数覆盖myCleanHook。

  3. 定义构建挂钩。此构建挂钩将make在命令行上运行以构建 C++ 和 C 部分，然后在创建链接 Haskell 绑定时使用 C 目标文件。

    我们开始myBuildHook：

    myBuildHook pkg_descr local_bld_info user_hooks bld_flags = do

    首先make不带参数运行：

    rawSystemExit normal "make" []

    然后将头文件和库目录的位置以及库本身添加到PackageDescription记录中，并使用新的包描述更新LocalBuildInfo ：

    let new_pkg_descr = (addLib . addLibDirs . addIncludeDirs $ pkg_descr)
    new_local_bld_info = local_bld_info {localPkgDescr = new_pkg_descr}

    在buildHook触发之前将configureHook编译顺序存储在记录的compBuildOrder（组件构建顺序）键中LocalBuildInfo。我们需要隔离库的构建，因此我们将构建过程的库构建和可执行构建部分分开。

    构建顺序只是一个列表，如果构建组件只是一个普通类型的构造函数，我们知道它是一个库，CLibName因此我们将这些元素从列表中隔离出来，并LocalBuildInfo只用它们更新记录：

    let (libs, nonlibs) = partition
                       (\c -> case c of
                                CLibName -> True
                                _ -> False)
                       (compBuildOrder new_local_bld_info)
    lib_lbi = new_local_bld_info {compBuildOrder = libs}

  4. 现在我们使用更新的记录运行默认的构建钩子：

    buildHook simpleUserHooks new_pkg_descr lib_lbi user_hooks bld_flags

  5. 构建完成后，已创建存档，但我们必须重新创建它以包含由make步骤 1 中的命令生成的 C 对象。因此，我们获取一些设置和 C 对象文件路径的列表：

    let verbosity = fromFlag (buildVerbosity bld_flags)
info verbosity "Relinking archive ..."
let pref = buildDir local_bld_info
    verbosity = fromFlag (buildVerbosity bld_flags)
cobjs <- getLibDirContents >>= return . map (\f -> combine clibdir f) 
                                      . filter (\f -> takeExtension f == ".o")

    然后将它交给withComponentsLBI哪个作用于构建的每个组件。在这种情况下，因为我们只处理库部分，所以只有一个组件。Cabal提供getHaskellObjects了获取 Haskell 目标文件的列表并createArLibArchive创建存档以便我们可以重新运行链接器：

     withComponentsLBI pkg_descr local_bld_info $ \comp clbi ->
  case comp of
    (CLib lib) -> do
              hobjs <- getHaskellObjects lib local_bld_info pref objExtension True
              let staticObjectFiles = hobjs ++ cobjs
              (arProg, _) <- requireProgram verbosity arProgram (withPrograms local_bld_info)
              let pkgid = packageId pkg_descr
                  vanillaLibFilePath = pref </> mkLibName pkgid
              Ar.createArLibArchive verbosity arProg vanillaLibFilePath staticObjectFiles
    _ -> return ()

  6. 在第 4 步中运行的默认设置buildHook创建了一个名为“package.conf.inplace”的临时包数据库文件，其中包含所构建库的描述，以便可执行文件可以链接到它，而无需将库安装到默认系统包文件。不幸的是，每次buildHook运行都会将其空白，因此我们需要保留一个临时副本：

      let distPref  = fromFlag (buildDistPref bld_flags)
      dbFile = distPref </> "package.conf.inplace"
 (tempFilePath, tempFileHandle) <- openTempFile distPref "package.conf"
 hClose tempFileHandle
 copyFile dbFile tempFilePath

  7. 现在我们将该副本的路径LocalBuildInfo与在步骤 3 中过滤掉的构建过程的可执行部分一起存储到结构中。

      let exe_lbi = new_local_bld_info {
                  withPackageDB = withPackageDB 
                                    new_local_bld_info ++ 
                                   [SpecificPackageDB tempFilePath], 
                  compBuildOrder = nonlibs
                }

    并将路径再次存储在extraTmpFiles部分中，PackageDescription以便可以通过默认清理挂钩将其删除。

    exe_pkg_descr = new_pkg_descr {extraTmpFiles = extraTmpFiles new_pkg_descr ++ [tempFilePath]}

  8. 现在我们终于buildHook在可执行组件上使用更新的记录（现在知道新存档）再次运行默认设置：

    buildHook simpleUserHooks exe_pkg_descr exe_lbi user_hooks bld_flags
于 2013-09-02T20:44:24.647 回答