Add Homebrew installation guide

[wxh06]

页面英文名

/tools/homebrew/

我希望能添加的内容是

macOS 下的管理器 Homebrew 的安装与使用。在 OI Wiki 中有多处出现了使用 brew 安装软件包的命令，但没有对 Homebrew 的安装作出说明。

本页内容包括：

1. 使用 USTC 镜像安装 Homebrew；
2. Homebrew 基本命令的介绍。

我了解到的相关参考资料有

USTC Mirror Help: https://mirrors.ustc.edu.cn/help/brew.git.html

[welcome]

感谢你对 OI Wiki 的关注！记得在 Issue 中表达清楚自己的意思哦～

[Rickyxrc]

这个建议自行查阅资料吧，因为macos的受众群体不广，homebrew也和OI没有太大关系。

仅作为个人观点。

[wxh06]

因为macos的受众群体不广

这倒是

homebrew也和OI没有太大关系。

是这样，但虽然事实上诸如 Git、LaTeX 的使用之类与 OI 也并没有直接关系，但是在工具软件中亦有介绍。

那是否有必要比如在编译器条目之中 macOS 安装 GCC 的位置增加安装 Homebrew 的命令（但是这样给人感觉页面的层级关系有问题）。

还有一种方案是为每个系统的包管理单独开专题，/tools/package-manager/apt/ /tools/package-manager/brew/ 或 /tools/package-manager/ubuntu/ /tools/package-manager/macos/ 之类的？

个人观点，待讨论。

[Enter-tainer]

我感觉现在这样就挺可以了吧？而且brew的安装本来就是一行命令

[wxh06]

我感觉现在这样就挺可以了吧？而且brew的安装本来就是一行命令

如果有梯子确实是一行命令，没有梯子的话光是安装脚本都 curl 不了。

[Enter-tainer]

@wxh06 啊？所以要从代理的配置开始讲吗

[Enter-tainer]

这种事情还是自己解决吧..

[wxh06]

啊？所以要从代理的配置开始讲吗

不讲代理啊，用镜像加文本替换啊。

[wxh06]

我的设想是可以比如开 macOS 系统安装软件的专题之类的东西，因为现在 OI Wiki 上面关于 macOS 的基本上就是看自己造化（

[Enter-tainer]

macOS 系统安装软件的专题之类

这..应该有这种主题的网站，但是我感觉oiwiki和这个的交集会比较小

[wxh06]

但是我感觉oiwiki和这个的交集会比较小

我主要的点在于 WSL 有专题但没有 macOS 环境搭建专题，作为mac批有点想补充一下相关的，如果没必要那也没关系就 close 掉了好了。

[Enter-tainer]

@wxh06 linux是因为noi会用呀。。

[Tiphereth-A]

事实上诸如 Git、LaTeX 的使用之类与 OI 也并没有直接关系。

Git 和 LaTeX 在算法竞赛的应用主要是出题人出题还有选手维护模板库，论相关性的话 homebrew 肯定比不过的吧 🤔

还有一种方案是为每个系统的包管理单独开专题，/tools/package-manager/apt/ /tools/package-manager/brew/ 或 /tools/package-manager/ubuntu/ /tools/package-manager/macos/ 之类的？

我觉得它们应该都有自己的官方文档？🤔

[wxh06]

linux是因为noi会用呀。。

我知道啊，但是 macOS 又没有类似 WSL 的东西啊。
而且在 Mac 上 Ubuntu 装磁盘分区比 Windows 麻烦，再加上 Apple Silicon 几乎没办法装原生 Ubuntu。那介绍在 macOS 下配置一个 OI 环境不是更显必要了吗？

[wxh06]

论相关性的话 homebrew 肯定比不过的吧

是这样，我完全同意这个观点。

我觉得它们应该都有自己的官方文档

你说的对，但什么东西是没有文档的？那 OI Wiki 存在的意义是什么呢？

[Tiphereth-A]

你说的对，但什么东西是没有文档的？那 OI Wiki 存在的意义是什么呢？

我觉得 OI Wiki 至少不是搬运产品文档的站点 :)

[wxh06]

我觉得 OI Wiki 至少不是搬运产品文档的站点 :)

您说的对，我无意跟您争论这个问题，我为我刚刚比较具有攻击性语言道歉。我非常敬佩这个项目给 OIers 带来的影响，也希望它变得更好更全面。（但是我只是觉得 Vim、VS Code 配置 Code Runner 等网上都有教程，OI Wiki 仍有收录，因此我不认为“搬运产品文档”是一个有力的论据，但我完全能够理解 Homebrew 不完全与 OI 相关没必要为它单独开新的页面）

我的本意是 macOS 配置 OI 环境教程，其中 Homebrew 是不可缺的一环，而这一部分恰好 OI Wiki 没有覆盖到。
对于一个使用 macOS 刚入门 OI 的学生来说，按照 OI Wiki 的现有内容是很难立刻开始使用标准的 GCC 工具链进行 OI 学习的，Xcode Command Line Tools 又恰好软链接了 gcc 的二进制文件到 clang，这是很可能对新手 OIer 造成困扰。

如果您觉得有必要，我可以撰写类似于 WSL 那一篇在 macOS 下搭建环境的内容。也谢谢你们今晚花费时间在这个问题上。

[r-value]

Xcode Command Line Tools 又恰好软链接了 gcc 的二进制文件到 clang

这个行为对 OIer 来说是透明的吧, 何来造成困扰呢? 在 OI 使用的范围内说 clang 是 gcc 的 complete drop-in replacement 没什么问题吧

[wxh06]

这个行为对 OIer 来说是透明的吧, 何来造成困扰呢?

是的，只要 --version 一下就行。只是我不了解究竟有多少人明确知道 macOS 里的 gcc 命令并不是真的 GCC（虽然很多人会在无法使用万能头文件时注意到这一点）。

$ gcc --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

在 OI 使用的范围内说 clang 是 gcc 的 complete drop-in replacement 没什么问题吧

GCC 不同版本行为也不同，以我参加 NOIP 时候使用的版本为例，GCC 4.8 版本 C++ 使用 freopen 必须要包含 cstdio；而使用 brew 能安装到的最旧的 GCC 4.9 只包含 iostream 也能通过编译。此外，有部分选手偏好于使用 bits/ 系列的头文件，这在 clang 里要进行修改 include path 之类的操作（当然啦，这完全是选手自己要注意的问题，只是我们可以在 Wiki 里指明这些问题从而帮助到更多人啦）

[inclyc]

我的本意是 macOS 配置 OI 环境教程，其中 Homebrew 是不可缺的一环

事实错误，理由如下：

gcc 对 OI 初学者并不是必须的

你实际上可以使用apple clang作为编译器，不一定非要用gcc。作为初学者很难体验到两者的差别¹。你体验到的差别更可能是由于C++标准库的实现不同，而非编译器实现不同²。

libstdc++ 也不一定需要 brew

在 macOS 上还有别的包管理器，包括macports，nix。brew并不明显优于它的竞争者³。

撰写新内容

如果您觉得有必要，我可以撰写类似于 WSL 那一篇在 macOS 下搭建环境的内容。

我觉得这或许是一个好主意，不过我担心你的安装方法过1年就坏了，然后没人继续维护。

或许可以自己写一篇blog，然后在OI-wiki中的资源链接收集处引流。

如果要写详细的安装教程，最好不要错误耦合无关组件，例如

“macOS的包管理器就是brew”³，
“clang下面就不能用bits/stdc++和pbds啦” ²
“C++的编译器就是gcc”⁴，
“Linux都有/usr”⁵，
“保护模式，实模式，线性地址”⁶。

C++ compiler support - cppreference.com

Footnotes

1. clang设计之初就是gcc的无缝替代，支持所有GNU扩展，包括一众pragma，attribute，_builtin* 如果有明显差别请向llvm-project提交issue，必要时可以CC我 ↩

2. 耦合编译器和标准库是新手常见误解。标准库和编译器集成度很高，但是是两个不同的组件，而clang编译器就可以同时支持libstdc++(GNU编译器套装提供的标准库），和libc++（llvm-project提供的标准库）。 ↩ ↩²

3. 或许在使用人数上确实更多。但我们不应该用使用人数来评价软件好坏。 ↩ ↩²

4. C++是一个语言标准，到现在为止有无数个编译器实现C++.https://en.cppreference.com/w/cpp/compiler_support ↩

5. 这是FHS的规定，而非内核的规定，做此假定会使软件可移植性变差。 ↩

6. 非常x86，不是体系结构通用的。 ↩

[inclyc]

clang 里要进行修改 include path 之类的操作

参见上一条评论，这不是include path的问题，而是选取C++标准库的问题。如果你在clang使用libc++的条件下用libstdc++的头文件，改include path很可能改出奇妙行为，两个库ABI是不兼容的。

[wxh06]

不过我担心你的安装方法过1年就坏了，然后没人继续维护。或许可以自己写一篇blog，然后在OI-wiki中的资源链接收集处引流。

很遗憾我自己没有写博客的习惯，目前也没有一个稳定的博客。至于维护，虽然AFO了，以季度为频率我应该还是没有问题的吧。

耦合编译器和标准库是新手常见误解。标准库和编译器集成度很高，但是是两个不同的组件，而clang编译器就可以同时支持libstdc++(GNU编译器套装提供的标准库），和libc++（llvm-project提供的标准库）。

受教了，我知道标准库实现和编译器实现是分开的，但我没有意识到 clang 可以直接使用 stdlibc++。

在 macOS 上还有别的包管理器，包括macports，nix。brew并不明显优于它的竞争者。或许在使用人数上确实更多。但我们不应该用使用人数来评价软件好坏。

我确实属于您所说的人数众多的 brew 用户，同时我是知道 MacPorts 的（非常抱歉之前没有了解过 nix，我注意到了您是 NixOS 的团队成员），不会写出“macOS的包管理器就是brew”这种话。

也谢谢 @inclyc 您的提醒，在写的时候（如果 OI Wiki 需要这方面的贡献的话）我会注意措辞的～

[inclyc]

如果 OI Wiki 需要这方面的贡献的话

首先非常感谢愿意贡献开源项目:heart:！

我不知道别的 OI-Wiki 编辑怎么想，但我觉得我们确实没有什么精力维护一些教程来教新手如何安装软件，并保证他们时效性（比如 OI-wiki 现在一些文章已经过时了）。

仅个人想法：可以做一个教程/资源收集页面，贴一些其他人在各种平台安装工具链的例子（例如一篇博客文章）。并且附带博客的发布时间，可以提醒教程可能过时。

但我没有意识到 clang 可以直接使用 stdlibc++。

跟话题无关，但是有两个有趣的事实：

1. clang 最开始没有自己的标准库，那时候标准库当然是白嫖的
2. clang 在Linux平台会默认使用 libstdc++, 也就是说其实可以使用 bits/ pbds 那些私货（ clang 和 gcc 本身的差别不是很大）

不会写出“macOS的包管理器就是brew”这种话

比较乐的是很多地方都在默认 brew 是 macOS 上的默认包管理器，这可能是因为大家默认“一个发行版就只有一个包管理器”，至少在 Linux 世界相对普适（也有一些奇特发行版可以用多个）。

不过我是 brew 黑头子

已经在某报群开喷了

[Rickyxrc]

看完上面的讨论，我认为我们需要对工具软件是否与 OI 有关做出更精确的定义。

仅按时效性定义是不精确的，我认为真正优秀的项目值得我们去积极维护它们的简单通俗的安装教程，以供更多人理解。

我的建议是将它们分为三档：

1. 和 OI 直接相关的软件/工具：如 dev-cpp / vscode / vim 等代码编辑器和某些 OJ 平台的插件。对于这些，我们可以给出内容和详细的教程，并在内容过期后积极维护。
2. 和 OI 没有太大关系，但是使用频繁的软件/工具：如 git / apt 等。对于这些，我们可以合并建成一个页面，并添加一些优秀的外链文章供参考，但是没有必要把宝贵的维护精力浪费在上面。
3. 和 OI 完全没有关系的软件/工具：如 mysql 等。我觉得 OI wiki 也没有太大必要维护这些，就让想了解的人自行查阅资料就好了。

所以我认为，我们有必要在近期对工具软件下的页面（ 即https://oi.wiki/tools 下的页面）进行重新维护翻新。

如果这有讨论价值的话可以新开 issue。