跳转至主要内容

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 将提供一种方法来保持主机和构建前缀分离，即使在非交叉编译时也是如此。这将避免对诸如“always_include_files”之类的需求，并有助于 conda-forge 保持其 llvmdev 配方不变（用于 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 脚本
      • 从 conda-forge 中央配置包重新渲染安装，使用该配置
      • 每个配方都可以在其 meta.yaml 文件旁边拥有自己的 conda_build_config.yaml 以覆盖任何内容
    • 中间文件存储在何处/如何存储，以及如何分配 CI 作业
      • John 建议在重新渲染期间将这些提交到 feedstock 仓库
      • Jonathan 想知道是否要将完整的 conda_build_config.yaml 提交到仓库，或者在构建时将其作为依赖项拉入，然后使用环境变量减少它。
      • Mike 想知道 CONDA_VARIANT_* 作为 CB 可能识别的环境变量模式，以便我们保留当前的 CI 方案。这可能也与 Jonathan 关于在每个作业基础上减少矩阵的想法相整合。Conda-smithy 将创建作业集，每个作业都具有不同的环境变量，以减少每个作业的总体矩阵。
  • 使用 run_exports 并使用 c-b-a 或 cb3
    • 人们普遍感兴趣，但需要随着时间的推移进行实施和验证。目前默认设置体验良好。

Windows 上的 Fortran 支持​

  • gfortran (msys2) / Flang
  • 添加任一方案的时间表
  • Mike 要求无论做什么都要经过社区批准，以维护高质量的用户体验。

OpenMP 行为​

  • 目前，mac 上需要额外的软件包，但 Linux 上已包含（尽管在标志中不活跃）
  • 理想的默认行为是什么？