假設您正在使用stack構建工具來製作Haskell庫（從Hackage導入包等）要與其中main位於C/C++中的C/C++項目一起使用。如何使用Haskell的堆棧構建工具導出要由C/C++使用的庫？
假設您的項目被命名爲Lib.hs（使用外部庫從hackage），有沒有使用堆棧導出方式你Lib.o，Lib.hi和Lib_stub.h要由C/C++編譯器像gcc或g++消耗？
編輯：一個相關的問題可能是：「怎麼能使用堆棧作爲構建工具，在其中main位於C/C++
一個Haskell & C/C++項目中使用EDIT2：經過反思，解決此問題的一種方法是像往常一樣使用Stack，但是將C/C++主要函數遷移到Haskell。這是實現它的最好方法嗎？是否存在巨大的性能成本？應該知道嗎？
堆棧不能真正做到這一點。
支持爲Cabal添加所謂的「外部庫」，但它尚未發佈。請參閱提交382143這將生成一個共享庫，該庫與所使用的每個Haskell軟件包的動態版本動態鏈接。
您可以使用堆棧構建包，然後事實上可以組裝一個本地庫。在Galua項目中，我們使用自定義的和單獨的linking script來執行此操作。
該鏈接過程的結果是，您將得到一個適合包含在C項目中的獨立靜態鏈接庫：libgalua.a。
請注意，要在Linux上創建適合鏈接到共享庫的獨立庫，您需要重新編譯GHC以生成PIC靜態庫（macOS默認執行此操作）。
重新編譯GHC只是爲了讓Linux在Linux上工作似乎相當艱鉅。你有什麼想法強制將C++項目移植到Stack項目中（Main位於Haskell中）？是否有任何內在的性能影響，或者我應該注意到的其他問題？ – George
也許這也可能是一種更好的方法，用GHC自己手動編譯所有haskell文件（甚至是從上游Hackage下載的庫;即，您必須自己下載它們並將它們添加到您的Makefile中）。畢竟，這是一個典型的C++項目如何組織自己的文件。那麼爲什麼不把這種做法擴展到C++項目中的Haskell呢？ – George
基本上：您的Galua項目經驗對此處的一些最佳實踐提供任何提示嗎？或者，你是否滿意你通過重新編譯GHC與PIC支持，然後使用堆棧輸出'libgalua.a'？的方法？ – George
「解決此問題的一種方法是像往常一樣使用Stack，但將您的C/C++主函數遷移到Haskell。」 - 這聽起來非常不理想。我不認爲這種可能性會使你原來的問題變得不那麼重要。 – duplode
在表現意義上欠佳？ – George
「在表現意義上不是最理想的？」 - 從這個意義上說，我真的不知道。我的意思是在項目組織方面並不理想。 – duplode