Question

我有一个Haskell项目，旨在创建一些C ++绑定。我编写了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文件中添加的，因为这就是我的实际项目，它是在构建步骤之前使用“make”通过Cabal构建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库。没有其他警告或错误。

Answer 1

要解决这个问题，我必须：

将Haskell库与C绑定的目标文件和
使用我的Cabal文件中的ghc-options标记，确保它们以正确的顺序链接。

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

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

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

重新链接Haskell库

通过添加：
将构建类型设置为custom
```
build-type: custom
```
到cabal文件。
通过将main方法替换为Setup.hs方法，插入自定义构建逻辑：
```
main = defaultMainWithHooks simpleUserHooks {
              buildHook = myBuildHook, 
              ...
       }
```
这告诉构建过程，它不应该使用simpleUserHooks中定义的默认构建过程，而应使用下面定义的myBuildHook函数。同样，使用自定义函数myCleanHook覆盖清理过程。
定义构建挂钩。这个构建钩子将在命令行上运行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}
```

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

buildHook simpleUserHooks new_pkg_descr lib_lbi user_hooks bld_flags

一旦完成构建已创建存档，但我们必须重新创建它以包含步骤1中make命令生成的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 ()

在步骤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
```

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

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

并将路径再次存储在extraTmpFiles的{{1}}部分中，以便默认清理钩子将其删除。

PackageDescription

现在我们最终再次使用更新的记录（现在知道新存档）运行默认的exe_pkg_descr = new_pkg_descr {extraTmpFiles = extraTmpFiles new_pkg_descr ++ [tempFilePath]}：
```
buildHook
```

静态链接C库和Haskell库

1 个答案: