跳到主要內容

2017-11-16 編譯器會議記錄

排定時間：中央時間上午 9 點。會議連結：https://anaconda.webex.com/anaconda-en/j.php?MTID=m11b5ddad66325da22bbe58d7d1c02809

採用 Anaconda 編譯器​

  • Linux：gcc 7.2

    • 帶前綴的編譯器：需要啟用
    • 新 anaconda 編譯器所需的常見調整

  • Mac：LLVM/clang 4.0.1

    • 帶前綴的編譯器：需要啟用
    • 新 anaconda 編譯器所需的常見調整

  • Windows：啟用腳本

    • 需要調整 Appveyor 編譯器位置
    • 常見的調整
      • cmake
        • 清除 CC 和/或 CXX 變數

    import os

    print("Hello World")

編譯器旗標統一​

總體而言：大家都樂於接受新的編譯器。Mike 將提供一種方法來保持 host 和 build 前綴分離，即使在非交叉編譯時也是如此。這將避免需要像 "always_include_files" 這樣的東西，並將有助於 conda-forge 維持其 llvmdev recipe 的原樣（用於 cling 用途）。

Filipe：這實際上只是一個供應商變更。我們已經依賴其他供應商的編譯器（RH 的 devtoolset2；蘋果的現有 clang），我們只是切換到不同的供應商，而不是從根本上改變我們所做的事情。

需要維護帶有 cling 修補程式的 llvm，但這不會是預設編譯器。

Conda-build 3：遷移策略​

  • 使用 c-b-a 安裝和使用（沒有 cb3 矩陣）
  • Mike：需要修復 —skip-existing。擔心的是，當只有某些依賴項發生更改時（錯誤修復 bump？），重新渲染不應生成新的套件。
    • Jonathan 將探索在僅雜湊值已更改時跳過上傳的方法，作為臨時的權宜之計。
  • 用 cb3 矩陣支援替換 c-b-a
    • 用中央 conda_build_config.yaml 替換 pinning script
      • 從 conda-forge 中央配置套件重新渲染安裝，使用該配置
      • 每個 recipe 都可以有自己的 conda_build_config.yaml，與其 meta.yaml 檔案並排，以覆蓋任何內容
    • 在哪裡/如何儲存中繼檔案和分配 CI 工作
      • John 建議在重新渲染期間將這些提交到 feedstock repo
      • Jonathan 想知道是否將完整的 conda_build_config.yaml 提交到 repo，或在建置時將其作為依賴項拉入，然後使用環境變數減少它。
      • Mike 想知道 CONDA_VARIANT_* 作為 CB 可能識別的環境變數模式，以便我們保留目前的 CI 方案。這可能也與 Jonathan 關於在每個工作基礎上減少矩陣的想法相結合。Conda-smithy 將建立一組工作，每個工作都有不同的環境變數，以減少每個工作的總體矩陣。
  • 使用 run_exports 並使用 c-b-a 或 cb3
    • 人們普遍感興趣，但需要隨著時間的推移實施和證明。到目前為止，使用預設值的經驗良好。

Windows 上的 Fortran 支援​

  • gfortran (msys2) / Flang
  • 新增兩者的時間表
  • Mike 要求無論做什麼都要經過社群批准，以維持高品質的使用者體驗。

OpenMP 行為​

  • 目前，在 mac 上需要額外的套件，但在 Linux 上已包含（但未在旗標中啟用）
  • 理想的預設行為是什麼？