構建和構建OCaml項目的首選方式是什麼？

生態系統新手尚不清楚建立和管理建築中小型OCaml項目的正規首選方式。我理解ocamlc,& c的基礎知識 - 它們反映了傳統的UNIX C編譯器，看起來很簡單。但是，在單個文件的一次編譯級別之上，不清楚如何最好地簡單幹淨地管理編譯。這個問題並不是在尋找潛在的工具，而是通過構建和建立標準的OCaml項目來看到一種或幾種正確的（足夠的）方法 - 正如社區的經驗所證實的那樣。構建和構建OCaml項目的首選方式是什麼？

我的模型用例是一個適度但不重要的項目，純OCaml或OCaml加上C依賴項。這樣的項目：

包含了一些源文件
鏈接到一些標準庫的
鏈接到一個或多個第三方庫
任選地包括C庫和OCaml的包裝爲的子項目（雖然這也可以單獨管理，並將其作爲一個第三方庫，如（3））

若干備選工具中脫穎而出：

自定義Makefiles似乎是大多數開源OCaml軟件包中的通用標準，但看起來令人沮喪和複雜 - 甚至比適度的C/C++項目更加如此。更糟糕的是，許多看起來很簡單的OCaml庫在autoconf/automake層上面更加複雜。
ocamlbuild似乎提供了一個現代的，簡化的機制，以最少的配置進行自動化構建，但對於新手來說並沒有很好的文檔記錄，也沒有在OCaml生態系統的介紹性材料中用實例代表，也沒有被任何已發佈的OCaml項目，我曾瀏覽過靈感。
OASIS似乎是其他構建系統頂層的約定和庫代碼層，以支持構建包管理器和庫，如Cabal。

（I也看到OMake，這似乎是一個自封「make++」，這也包括一套共同語言，包括OCaml的標準規則，以及ocaml-make孃家姓OCamlMakefile，提供的標準規則的模板對於GNU make。）

這些是管理OCaml構建的首選的現代方式嗎？

項目文件的結構如何？

如何包含和管理第三方庫依賴項？是否希望在系統級別安裝它們，或者是否存在以本地方式管理項目的標準和直接方式？我更喜歡一個模型，儘可能保持項目的獨立性。

來源

2011-05-10 jrk

的ocamlbuild鏈接（現在）打破了。 –

鏈接現已修復 – ygrek

你已經有了可用選項的完整列表，但是這個問題沒有明確的答案。我個人的建議也是使用ocamlbuild。 myocamlbuild.ml文件提供的here是一個好的開始。它將允許您輕鬆編譯依賴各種庫的項目。我認爲它不處理綁定到C庫的情況，但在wiki上有其他示例可能有所幫助。

有些人反對ocamlbuild，因爲它是另一個構建工具，使包管理器作業變得複雜。然而，它的易用性和包含在官方發行版中的事實正在使其越來越廣泛地被使用。

你也可以跳過所有這些並直接使用綠洲。這是非常新的，穩定的版本尚未公佈，但它非常實用。它會自動爲你生成myocamlbuild.ml。如果不是這樣的話，這很可能是不久的將來。此外，通過使用綠洲，您將立即獲得oasis-db的好處，這是一個正在開發的OCaml CPAN系統。

關於管理庫，答案是ocamlfind。如果您安裝了多個OCaml實例，則調用ocamlfind的相應副本將自動使所有對庫的引用都成爲那些特定實例的引用，假設您對所有庫都使用ocamlfind進行系統化。我目前使用godi來安裝OCaml和庫。它使用ocamlfind，並且我沒有安裝多個OCaml實例的問題。

來源

2011-05-11 12:43:56

這個答案已經差不多三年了。我想分享我作爲新人的經驗。在經歷了很多痛苦之後，我得出結論，通過ocamlfind來吞噬文檔並使用ocamlc，ocamlopt和ocamlmklib是構建OCaml項目最痛苦的方式。我在這裏記錄了我的發現https://github.com/pacemkr/ocaml-scrypt/blob/master/Makefile我確定'oasis'是一個'myocamlbuild.ml'文件解決真正的問題。我嘗試了，我確實有過，但是這兩種工具在抽象其複雜性方面失敗慘重。 –

我認爲我的回覆也過時了。最近我一直在使用[OMake]（http://omake.metaprl.org/），但我對所有的構建工具並不滿意，希望最終會有一些基本上更好的東西出現。 –

事情正在改善，「opam」並不關心構建系統，這很好。 'ocamlfind'使得使用'ocamlc'和朋友更容易。這兩個讓我足夠接近。最難的部分是理解所有中間工件（cm *）以及它們來自哪裏，以及'cclib'和類似標誌的間接方式，它們如何與包一起傳遞，定製運行時構建等。 –

就我個人而言，我會給ocamlbuild +1。它的默認規則足夠用一個命令編譯小型到中型項目，而沒有一個編譯器的配置很少。它還執行一些非常合理的約定（不會混合源代碼和構建結果）。而對於較大的項目，可以根據自己的願望進行定製，使用額外的規則&插件。在我工作的公司，我們使用它作爲large project（Ocaml +一些C +一些預處理+ ...），它的功能就像一個魅力（並且讓我們比Makefiles更少麻煩）。

至於手冊，我認爲用戶指南（可從author's webpage，）應該足以讓你開始。更時髦的東西可能需要更多的挖掘。

來源

2011-05-10 21:45:01 akoprowski

完全同意。我參與了一個使用ocamlfind，預處理和c的大型項目，但沒有太多問題。 – nlucaroni

在我的平行調查中，這似乎是最有吸引力的。一旦我開始跟蹤它，我會報告回來。 – jrk

對於所有ocamlbuild粉絲來說：記住*你*可以通過幫助編寫文檔，發佈自己感興趣的自制'myocamlbuild.ml'文件的片段，甚至可能對代碼做出貢獻來改進該工具（但爲此你應該首先與開發者聯繫），以獲得你想要的功能（我的願望清單中的簡單目標：允許調用ocamldoc來生成點圖）。 – gasche

對於OMake +1。

我們幾年前裝修了的基礎設施建設，並選擇OMake，原因如下：

我們的產品是由C，C++，託管C++，Ruby和OCaml中的混合物。
我們既定位Linux又定位Windows。
我們在構建時與數據庫進行交互。我們不得不使用OCaml 3.10。
我們的原始構建系統使用了autoconf/automake。
我們需要源代碼構建*。

說實話我不知道我們是否可以用ocamlbuild做到這一點，我還沒有測試過。由於OCaml的bug追蹤器中存在一些活動，因此該工具確實在使用。如果您選擇ocamlbuild，請確保您有最新版本的OCaml。

* OMake支持亂源建立在一個位非顯而易見的方式。當來源爲只讀時，它也有一些問題。我們必須修補和重建我們的Windows版本的OMake。

來源

2011-05-11 13:51:07 bltxd

我想看看omake和ocamlbuild之間的比較。我已經使用omake取得了很大的成功。當我嘗試ocamlbuild時沒有那麼多運氣，但那是幾年前。 – aneccodeal

很好的問題。我傾向於這樣說：

1）ocamlbuild 它很可能是編譯的標準方法，因爲它是高效的，快速的，並且是官方發佈的默認工具。事實上，這是官方發佈的事實，因爲它更有可能隨時間而停滯。此外，它已啓用ocamlfind，因此它可以管理使用ocamlfind安裝的軟件包，這是安裝軟件包的另一個標準（ocamlfind有點像C的pkg-config）

2）但它不足以滿足您的項目。與C的集成與ocamlbuild基本相同。所以在這裏，我可能會建議你使用綠洲來最終回答你的問題。我也嘗試過OMake，但不喜歡它。

3）但是，如果您不希望其他人能夠在自己的機器上下載和構建項目，那麼您的構建腳本不太可能正常工作。此外，綠洲不處理pkg-config。出於這些原因，我傾向於建議您使用ocaml-autoconf（ocaml宏用於autotools）。因爲autotools是管理C庫的標準，並且它被包維護者所熟知。它也可以處理交叉編譯...

=>的OCaml的autoconf與ocamlbuild

來源

2012-05-22 17:57:58 william3

構建和構建OCaml項目的首選方式是什麼？

回答

相關問題