Lapack: 构建系统

要添加到列表中，CMake 构建当前（似乎）支持仅构建库的选择部分（REAL、DOUBLE、COMPLEX 和/或 DOUBLE COMPLEX）的选项，而仅 Makefile 构建不支持。 （我已经更改了我们与 OpenBLAS 一起分发的副本中的 Makefile，并且可以根据需要生成 PR - 需要重新比较以省略一些此处不相关的更改）

CMake 构建当前（似乎）支持仅构建库的选定部分（REAL、DOUBLE、COMPLEX 和/或 DOUBLE COMPLEX）的选项

此选项在我上次尝试时有效（大约 2020 年 5 月）。

CMake 构建有几个选项，我在这里列出了对我来说最重要的选项：

• 构建共享或静态库
• 启用或禁用测试
• 64 位或 32 位索引
• 优化和调试构建
• 矩阵生成器库 (TMG) 的选项、其他 BLAS 库的使用、BLAS++、LAPACK++...

好主意。 使用 make 在我的机器上构建而不是使用 CMake 在 ci 上构建，这让我发疯了几次。

从技术上讲，我认为 Makefile 也支持很多这些选项（你可以编辑你的 make.inc）。 如果你想要一个没有测试的构建，你可以用make lib构建。 但至关重要的是，不支持构建共享库。 大多数人使用 LAPACK 作为共享库，这使得 CMake 成为我的明显赢家。

如果我们最终选择了它，我建议我们在自述文件中添加一些额外的构建说明。 如何构建和运行测试，如何添加标志，尤其是 frecursive 标志。 也许甚至是关于如何使用共享库的一些小笔记。

我怀疑已经有很多补丁（例如在打包 lapack 的 linux 发行版中）来使用 gmake 构建共享库。 将 BUILD_SHARED 选项添加到 make.inc 应该不会太复杂，就像已经存在的 BUILD_DEPRECATED 一样（除非已经知道 ccmake 和 cmake-gui 存在，否则两者在 CMake 构建中都很模糊）。

将 BUILD_SHARED 选项添加到 make.inc 应该不会太复杂，就像已经存在的 BUILD_DEPRECATED 一样（除非已经知道 ccmake 和 cmake-gui 存在，否则两者在 CMake 构建中都很模糊）。

无需使用ccmake来设置任何这些选项。 您可以使用类似于 autotools 生成的configure脚本的命令行：

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

你当然可以，我的观点是除了阅读 CMakelists.txt 之外没有明显的文档（而自述文件指向 gmake 的预配置 make.inc 文件）。 ccmake 和 cmake-gui 显示了一个可用选项列表，但是任何新接触 cmake 的人都会丢失这些选项。

如果我们写了一个关于如何使用 CMAKE 的文档，我们可以将我用作豚鼠用户，因为我从未使用过 CMAKE。

阅读整个对话，我觉得 Makefile 在 LAPACK 中只为我而存在。 ;)

好吧，我不知道。

是的：维护多个构建系统会导致不一致。 所以我看到只有一个的论点。 （无论是 CMAKE、make 还是介子。）（哦，是的，我也从未使用过介子，如果你想知道的话。）

我很担心搬到 CMAKE 因为，我不仅不知道如何使用它，而且我不知道如何维护它。 然而，我们似乎有一个很棒的社区可以提供帮助，所以我不能在项目的这部分工作似乎不是问题，此外，我可能应该学习 CMAKE。

全体：请在此线程中发表您的意见。

似乎我们大多数人都想（1）移除 make 并移除介子； (2) 只移动到 CMAKE； (3) 添加一些关于如何使用 CMAKE 的好文档。 我都可以。

我将在这里和那里向其他软件包维护者发送几封电子邮件，询问他们的工作情况以及他们对这个问题的看法。

@martin-frbg：这是如何在 OpenBLAS 中完成的？

OpenBLAS 将 Makefiles 作为其“已知可以工作”的“传统”构建系统，而 CMAKE 作为最初由用户提供的替代方案，它仍然发出警告，即它生成的文件可能与 Makefile 构建的内容不完全对应。
我不太喜欢 CMAKE，但我已经学会了创建工作（尽管有时可能是非正统的）cmake 构建文件。 在我看来，Makefile 应该保留（我相信 gmake 仍然比 cmake 更广泛）。 我不知道介子支持的历史 - _if_ 这是一次“抛开围栏”的贡献，没有人知道或关心足以保持更新，我想保留它没有什么意义。

我不知道介子支持的历史 - 如果这是一次“抛开围栏”的贡献，没有人知道或关心以保持更新，我想保留它没有什么意义。

Meson 版本在 PR #311 中被空降到 LAPACK 中。

嗯。 如果它被 3.9.0 接受（即使只是作为概念证明），那么在下一个版本中再次将其丢弃看起来会有点奇怪......

我联系了@therault，以便他可以给我们他的意见，这是@therault所说的。 谢谢@therault！

Open MPI 仅使用 autoconf（automake、autoconf、configure、Makefiles）。

对于PaRSEC和DPLASMA，我们只使用CMake，为了帮助习惯配置的用户， @abouteiller制作了一个脚本，使用configure的语法，并用自己的语法调用CMake。

我知道有一个主要项目试图同时维护 configure 和 CMake。 它在 CMake 中 100% 的功能可用，并且配置中支持的新功能越来越少的情况下缓慢发展。 我相信他们已经停止维护配置版本。

为一个代码维护两个构建系统是很困难的：理论上，构建系统应该适用于任何代码，因此维护两个应该是可能的（维护人员的成本很高，要保持它们同步，这就是为什么配置被丢弃在另一个项目中，维护者决定他有更好的时间去做）。 在实践中，有时需要使代码适应构建系统以使事情更简洁。 发生这种情况时，两个构建系统中的一个需要使用变通方法和 hack 来像另一个构建系统一样并按照代码运行。

最后，无论是 CMake 还是 configure，都会让人失望。 我们是程序员/数学家/我们做算法......花时间去理解为什么在那台机器上，使用编译器和标志的这种组合，代码不能正确编译，没有人喜欢这样。 更糟糕的是，试图找到如何使用 CMake 或 autoconf 来做那件事或其他事情会让你望而却步:) 与两者一起工作，我可以保证你会抱怨他们两个:) 维护一个是肯定的方法少抱怨两次。

今天，我支持 CMake 有一个原因：CMake 在生成 Ninja 文件而不是 Makefile 方面做得很好。 Ninja 编译 PaRSEC 的速度比 Make -j 快两到三倍。 现在，也许configure/autoconf也可以生成Ninja文件，我没试过……如果你之前没试过ninja，如果LAPACK有CMake版本，我建议你试试cmake -G Ninja（在你的机器上安装Ninja之后）。 要编译，您在执行 cmake 的目录中调用 'ninja' 而不是 'make'。 你会看到，这太棒了:)

如果您对此感兴趣，我很高兴将上述 configure-to-cmake 胶水脚本贡献给 LAPACK。
（澄清一下，该脚本不是基于 autoconf/m4 的，它是一个简单的脚本，可将configure --with-feature=value转换为对cmake -DFEATURE=value的调用，并稍加修饰）。

LAPACK 甚至不使用配置——我同意让基于 autoconf/automake/configure 的系统与 cmake 并发可能会很痛苦，因为 autotools 本身不断“进化”并依赖于 m4 宏等等。

我很担心搬到 CMAKE 因为，我不仅不知道如何使用它，而且我不知道如何维护它。

这是坚持使用 Makefile 的一个主要原因。

全体：请在此线程中发表您的意见。

介子构建应该被删除。 没有人在使用它，没有人知道如何维护它，原作者提交了一个不完整的构建，并且在他的更改合并后再也没有回来。 在我打开这个 issue 之前，有多少人知道有一个 Meson 构建？

CMake 是一个可移植的构建系统，具有简单的语法和完全可配置的构建。 可以设置特定于文件、特定于编译器或特定于目标的选项（例如，有选择地启用不在 C 标准库中的函数，如gethostname() ）。 CMake 具有强大的对象文件管理功能； 这允许您继续输入make来更新您的构建，即使您切换了 git 分支。 CMake 与 UNIX 生态系统的其余部分很好地交互：您可以调用任意程序并对它们的输出进行操作。 例如，您可以调用 pkg-config 来定位其他软件包。

我第一次使用 CMake 是在 2016 年，此后我一直使用它在 x86、x86-64、armv7 和 aarch64 指令集架构上为 Linux、Mac、iOS 和 Android 系统构建代码。 它适用于所有主要的 Linux 发行版和我可以访问的所有超级计算机（Grid 5000、Jean Zay、JUWELS、GRICAD、Eagle II）。 超级计算机通常有多个可用版本，包括旧版本和最新版本 (3.18+)。 我在 CMake 可用性方面遇到困难的唯一平台是 CentOS 7，但您始终可以下载 CMake tarball 并使用 tarball 中的引导脚本仅使用 GNU Make 构建 CMake。

CMake 只为我工作。

我使用其他构建系统的经验如下：

• Bazel：一个巨大的内存猪，不可能在 1GB 内存的 Raspberry Pi 上运行，坚持构建所有依赖项，并静态链接所有内容
• 自动工具：作为一个开发者没有经验，为用户的configure脚本是非常方便，因为它可以显示所有可用的选项（CMake的不与ccmake运行后仅cmake一次）。

今天，我支持 CMake 有一个原因：CMake 在生成 Ninja 文件而不是 Makefile 方面做得很好。 Ninja 编译 PaRSEC 的速度比 Make -j 快两到三倍。

太好了，Ninja 过去无法编译 Fortran，参见。 ninja #1265 ，即，在某些发行版上这是行不通的（Debian 9？）。

在这种情况下，我肯定会说常规的 makefile 更容易和足够。
在 HPC 集群中维护软件 我对 Cmake 的使用感到非常失望。

1. 由于过多的文档阅读，开发人员很难遵循标准命名方案，从而使构建变得困难。 每个包都会对适合其项目的名称进行一些“调整”。 因此以非标准命名方案结束。 （对于 autoconf+ 有点正确，但这里的东西标准化了更多）
2. 当 cmake 出现问题时，它需要一个 cmake 专家来调试它，我仍然很难调试东西...... :(
3. 难以使用配置文件（没有make.inc ），这会强制在构建时在命令行上指定所有bulild-options。

另一方面，cmake 也做得很好：

1. 更简单的 Windows 支持
2. 更自动地处理依赖项并为其他项目包含 cmake 文件（这是一个很好的好处）

但是，对于 LAPACK 非常简单的构建系统，我认为没有好坏之分。 当前的构建系统已经运行了几十年，人们已经习惯了。
此外，对于快速并行构建，这可以轻松地添加到当前的 makefile 系统中...

我真的没有偏好，但是如果支持更多选项，应该

我觉得我和你的情况类似@langou 。

我不知道cmake。 我只是设法将它用于这个项目，因为所有配置都已经到位，并且通过打开 travis 配置并复制粘贴它执行的行。 我不认为这只是因为我没有经验。 Makefile 没有那么神奇，感觉更低级。 这可能会引起那些倾向于从事这个项目的人的共鸣。
如果纯粹为了我个人使用，我会继续使用 gmake，但是我们必须将当前仅在 cmake 中可用的所有功能放入 Makefile 中。 尤其是共享库目标。

但是，我不能忽略 cmake 似乎提供的所有不错的功能。 最终，我认为 cmake 或 gmake 都可以。 我们只需要选择一个。

我是一个外部声音，但作为帮助在 conda - forge 中维护 lapack 的人，将构建系统设为 CMake 将有几个优势（更少的hacky ，本机 Windows 支持等）。

习惯 CMake 语法需要一些时间，但我的印象是它是一个维护良好且文档齐全的软件，已成功解决/抽象掉了许多棘手的构建问题。 我也参与了其他库的打包工作，并且（主观上）看到越来越多的人转向 CMake。

只是来自外部的另一个数据点； 在我们的工作中涉及相当多的 C/C++ 构建，我们在与 CMake 斗争太多之后转向了 Meson。 它的一长串问题在其他地方都有详细记录，所以我跳过了这些。

在 SciPy 项目中，由于 Python distutils正在退役，我们还将在某个时候尝试使用 CMake 或 Meson。

我同意维护三个构建系统会导致维护人员的不一致和/或额外的工作。 但是，根据上面的评论，在我看来，每个用户都有自己的方式来构建代码。 特别是，我同意@therault的评论：

我们是程序员/数学家/我们做算法......花时间去理解为什么在那台机器上，使用编译器和标志的这种组合，代码不能正确编译，没有人喜欢这样。 更糟糕的是，试图找到如何使用 CMake 或 autoconf 来做那件事或其他事情会让你望而却步:) 与两者一起工作，我可以保证你会抱怨他们两个:) 维护一个是肯定的方法少抱怨两次。

绕过多个构建系统问题的一种想法是：

• 在 CI 中创建更多配置，使其涵盖所有支持的构建系统。 通过这种方式，我们保证所有构建系统都能使用基本功能。
• 在 README 中展示所有并建议使用构建系统之一。 例如：_如果您需要构建共享和静态库，我们建议使用 CMake，..._，正如@martin-frbg、@christoph-conrads 和@thijssteel在此线程中所述。 （我不知道存储库中有 Meson 构建系统。我认为我们应该将其添加到 README 中或停止维护此选项。）

据我了解， recursive标志的问题与xeigtstz测试例程有关（请参阅 https://github.com/Reference-LAPACK/lapack/issues/335#问题评论-485021575）。 当这个问题得到解决时，我的意见是我们将决定要么

1. 将该标志添加到默认的 CMake 配置以及缺少的其他任何地方，或者
2. 从make.inc.*文件中删除标志。

我认为对-frecursive轻微误解 - 这是多线程代码正确运行所必需的，因此通常不应从构建文件中删除。 然而，一个副作用是它将本地数组放在堆栈上，这在 xeigtstz 情况下非常大。 从（仅）TESTING/EIG Makefile 中删除此选项在简单情况下似乎会有所帮助，但在使用“-fopenmp”编译时似乎暗示了这一点，因此对于该测试的异常大的堆栈限制要求，这不是通用的解决方案。

所以这就是原因。
我同意 LAPACK 是一个“简单”的库——只要有一个 make 系统就足够了，而且很长一段时间就足够了。
但是但是但是......有Windows..并且仅仅因为Windows，我们不得不带上cmake。 最初，来自 CMake 的人致力于配置，但现在我想我们是靠自己的，就像@langou一样，我们并没有真正掌握它。
现在大多数基于 LAPACK 的软件都在使用 Cmake，我们从用户反馈中知道，他们喜欢它。

因此，如果我们必须选择一个构建系统：这必须是 Cmake ......目前不幸，但幸运的是未来。

我的投票：遵循@abouteiller和 @@ therault的建议并且只有一个构建系统，因此是 cmake。

现在大多数基于 LAPACK 的软件都在使用 Cmake，我们从用户反馈中知道，他们喜欢它。

我打开了这个 issue 并建议只有一个构建系统。 我的假设是 Makefile 和 CMake 技能大致均匀分布。 如果我错了，请纠正，但我的印象是，这在常规 LAPACK 贡献者中并非如此：Makefiles 似乎很受欢迎，而 CMake 知识似乎并不强。 此外，经过两天的讨论， -frecursive标志显然是 CMake 和 Makefile 构建之间的唯一区别，而且 Travis CI 中仅使用了 CMake。 如果它赶走了核心贡献者，那么强制建立一个让用户满意的构建系统是没有意义的。

（我对谁是常规贡献者的判断是基于查看已接受的拉取请求的前五页。）

同意..顺便说一句，递归标志位于默认的 CMake 和 Makefile 配置中，#492。 所以，我认为我们只需要在 Travis CI 中包含 Makefile 构建。

PR #500 减轻了此处报告的 Makefile 和 CMake 构建系统之间的不一致。 见https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

嗨@ilayn。 感谢 Meson/CMake/Makefile 信息。 获得外部反馈并获得有关其他项目正在做什么的信息是很棒的。 我们无法支持所有三个系统，我们现在更喜欢 CMake 和 Makefile，因此我们可能会停用 Meson。 并不是说我们永远不会使用 Meson，但就目前而言，我们没有资源来维护它。 这是我的意见。 我想我们很快就会提交一个 PR 来让 Meson 退役。 朱利安。