ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

在 macOS 上搭建 .NET runtime 仓库构建环境:Xcode 与工具链依赖完整指南

在 macOS 上搭建 .NET runtime 仓库构建环境:Xcode 与工具链依赖完整指南 在 macOS 上搭建 .NET runtime 仓库构建环境Xcode 与工具链依赖完整指南【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读本文面向希望在 macOSIntel 或 Apple Silicon上编译 dotnet/runtime 仓库的开发者完整讲解两大前置条件Xcode 开发者工具的安装与命令行工具配置以及CMake、icu4c、pkg-config、python3、ninja等工具链依赖的获取方式。读完本文你将能够独立完成 macOS 构建环境的初始化理解仓库提供的install-dependencies.sh一键安装脚本的底层逻辑并知道如何验证环境、启动首次构建。该文档的原始出处为 docs/workflow/requirements/macos-requirements.md是 构建工作流总览 中构建平台环节的 macOS 专章它与 Linux 环境要求、Windows 环境要求、FreeBSD 环境要求 共同构成各平台的环境准备矩阵。Xcode Developer Tools要在 macOS 上构建本仓库第一步是安装 Apple 的Xcode开发者工具可从 Mac App Store 获取。它提供的不只是 IDE更关键的是为编译 CoreCLR / Mono 原生代码C/C所需的编译器Clang、链接器、SDK 头文件与系统库。安装与命令行工具配置安装完 Xcode 后必须确保Xcode 命令行工具Command Line Tools指向该安装通常有两种方式任选其一方式一通过 Xcode 图形界面推荐最直观运行 Xcode打开Preferences偏好设置在Locations位置选项卡中将Command Line Tools下拉项切换为当前安装的Xcode.app。文档说明该选项通常默认已指向正确位置但确认一遍更稳妥。方式二通过终端命令适合自动化与远程环境sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer此命令假设你的 Xcode 应用名为默认的Xcode.app。如果你重命名过它请相应调整路径后再执行。验证命令行工具是否生效仓库自身的脚本会在安装依赖时主动探测 Xcode 环境。查看 eng/common/native/install-dependencies.sh 的 macOS 分支第一条命令就是echo Installed xcode version: $(xcode-select -p)它会输出当前生效的开发者目录路径例如/Applications/Xcode.app/Contents/Developer这正是验证xcode-select配置是否正确的快速手段。你可以在终端手动执行xcode-select -p做同样的检查如果路径与你安装的 Xcode 不符则按上文方式二重新切换。补充提示针对 iOS / iOS Simulator / Mac Catalyst 等移动平台的构建见 CoreCLR 的 iOS 构建文档除了上述基本配置外还需要在 Xcode 中启用对应 SDK并执行xcode-select --install安装命令行工具同时接受 Xcode 许可证协议sudo xcodebuild -license否则构建会在工具链探测阶段失败。Toolchain Additional Dependencies除 Xcode 外构建本仓库还需要以下工具链依赖均为原生构建阶段所需主要用于 CMake 驱动的 CoreCLR / Mono 编译与库打包依赖版本要求作用CMake3.26 或更新跨平台原生构建系统生成器驱动 CoreCLR / Mono 的 C/C 构建icu4c随 Homebrew 最新版即可国际化组件库.NET 全球化功能如字符串比较、日历、时区的底层实现pkg-config无特殊要求在 configure 阶段查找第三方库的头文件与链接参数python3无特殊要求仓库大量构建/生成脚本.py的解释器ninja无特殊要求高性能原生构建驱动在非 Windows 平台默认使用其中CMake 3.26是硬性下限本仓库的 CMake 构建脚本依赖较新的生成器能力与特性开关版本过低会直接导致 configure 失败。手动安装不使用脚本如果希望自行管理依赖可通过 Homebrew 逐项安装brew install cmake icu4c pkg-config python3 ninja也可以按需使用brew install 包名单独安装某一个依赖。一键安装使用仓库提供的 install-dependencies.sh推荐文档推荐的首选路径是先安装HomebrewmacOS 的包管理器然后从仓库根目录直接运行脚本一次性下载并安装全部必要依赖./eng/common/native/install-dependencies.sh该脚本支持跨平台使用在不传参时它会自动调用 eng/common/native/init-os-and-arch.sh 探测当前系统脚本内部通过uname -s识别将darwin归一化为osx再进入对应的安装分支。你也可以显式传参指定目标系统例如./eng/common/native/install-dependencies.sh osx脚本同时支持maccatalyst、ios、iossimulator、tvos、tvossimulator等 macOS 衍生目标这些参数在交叉构建移动平台产物时很有用。脚本源码剖析install-dependencies.sh 在 macOS 上做了什么深入阅读 eng/common/native/install-dependencies.sh其 macOS 分支osx|maccatalyst|ios|iossimulator|tvos|tvossimulator的执行逻辑可以拆解为四步1. 探测并输出 Xcode 环境echo Installed xcode version: $(xcode-select -p)2. 导出 Homebrew 行为环境变量抑制冗余操作export HOMEBREW_NO_INSTALL_CLEANUP1 export HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK13. 显式跳过brew update脚本注释中引用了社区已知的brew update --preinstall卡顿问题避免在 CI 场景浪费时间。4. 通过brew bundle以 stdin 方式批量安装依赖清单brew bundle --no-upgrade --file- EOF brew cmake brew icu4c brew openssl3 brew pkgconf brew python3 brew pigz brew ninja EOF注意两点与文档清单的差异这正是源码级细节脚本额外安装了openssl3.NET 安全栈在 macOS 上链接的 OpenSSL 提供方与pigz并行 gzip用于packs子集生成 tarball 时加速压缩脚本安装的是pkgconfpkg-config的现代实现提供同名pkg-config命令与文档中安装pkg-config的表述是同一需求的两种包形式。brew bundle --no-upgrade表示不升级已装包、仅补齐缺失项保证脚本可重复执行且不会意外改动现有版本。环境就绪后验证与首次构建支持的构建平台组合根据 docs/workflow/README.md 的构建平台支持矩阵macOS 作为构建平台支持 x64 与 Arm64 两种架构x86、Arm32 不支持。同时要注意构建平台运行编译工具的机器与目标平台产物运行的平台可以不同后者即交叉编译在 Intel Macx64上可以交叉编译 Arm64 产物在 Apple Silicon MacArm64上还可以交叉编译回 x64 产物参见 CoreCLR 构建指南 的兼容矩阵。验证依赖并触发构建依赖安装完毕后推荐手动复核一遍各工具版本cmake --version pkg-config --version python3 --version ninja --version xcode-select -p随后即可从仓库根目录运行主构建脚本开始首次编译示例为仅构建 CoreCLR 运行时./build.sh -subset clr常用构建参数说明详见 构建工作流总览-subset指定构建组件多个子集用连接如clrlibs支持clr、libs、packs、host、mono等-configuration / -c全局构建配置可选Debug默认、CheckedCoreCLR 专有带断言且已优化、Release-runtimeConfiguration / -rc、-librariesConfiguration / -lc为不同子集指定不同配置非 Windows 平台的长参数可写单横线或双横线如-c与--configuration等价。macOS 特有的构建调优若希望获得更好的原生调试体验可在构建 CoreCLR 时开启.dSYM调试信息生成。默认情况下 macOS 构建只产出.dwarf符号文件LLDB 无法自动关联源码开启后 LLDB 可直接显示源码行号与符号详见 CoreCLR 构建指南的 macOS 调试节./build.sh -subset clr -cmakeargs -DCLR_CMAKE_APPLE_DYSMTRUE常见问题与注意事项Xcode 路径被修改后构建报错若xcode-select -p输出非预期路径重新执行sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer。CMake 版本不足若cmake --version低于 3.26请通过 Homebrew 升级brew upgrade cmake切勿直接复用系统自带旧版本。脚本需在仓库根目录执行install-dependencies.sh的调用约定是从仓库根目录运行./eng/common/native/install-dependencies.sh脚本使用set -e任何一步失败都会立即中止便于定位问题。磁盘与网络占用克隆本仓库全量历史约需 400–500 MB 网络传输仓库膨胀后占 1–1.5 GB单平台单配置的一次构建约需 10–20 GB 磁盘空间见 docs/workflow/README.md 的说明请预留足够空间。Docker 替代方案若不想在本机安装任何依赖也可以参考 使用 Docker 构建直接复用官方构建镜像该方案对应 Linux 环境要求文档 的 Docker 章节。完成以上步骤后你的 macOS 机器即可编译 CoreCLR / Mono 运行时与 .NET 类库并可通过corerun、Core_Root 或 dev shipping packs 对构建产物进行测试与调试。【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表