| 27 Nov 2025 |
 Picnoir | Hm, strange. | 18:47:19 |
| Picnoir | No logs in stdour/err? | 18:47:26 |
 samasaur | Randy Eckenrode: Am I correct in assuming both apple-sdk and cctools don't have manpages to reduce the size of the stdenv closure? | 19:57:25 |
| samasaur | I'm looking at https://github.com/NixOS/nixpkgs/issues/456879 and thinking about whether it's possible to get those manpages in at least interactive dev shells | 19:57:42 |
 Randy Eckenrode | They’re disabled because otherwise they pull in llvm-manpages, which has a ton of build deps. | 19:58:09 |
| Randy Eckenrode | Like if you don’t disable tests, you end up pulling ffmpeg i to the bootstrap. | 19:58:38 |
| Randy Eckenrode | * | 19:58:44 |
| samasaur | oh blegh | 19:58:44 |
| samasaur | what about the SDK manpages? | 20:06:08 |
| samasaur | https://github.com/NixOS/nixpkgs/blob/ffe72c37cd240ca7043055765c1ae22678ce4638/pkgs/by-name/ap/apple-sdk/common/fetch-sdk.nix#L32-L33 | 20:06:09 |
| samasaur | looks like they're just explicitly removed | 20:06:13 |
| samasaur | which i assume is for size? | 20:06:19 |
| Randy Eckenrode | More to avoid redistributing stuff we don’t need or can rebuild ourselves. | 20:08:29 |
| Randy Eckenrode | Particularly since we ship more LLVM tools (ideally 100% in 26.05) than Apple does. I don’t want to conveniently ship wrong documentation. | 20:10:24 |
| Randy Eckenrode | If people really need man pages, they can add llvmPackages.llvm-manpages to their dev shells. | 20:10:48 |
| Randy Eckenrode | If there’s a way we can make it available automatically in dev shells, we can do that to improve the UX. Otherwise, it can be in the stdenv because it would pull a bunch of Python deps into the bootstrap. | 20:12:56 |
| samasaur | isn't llvm-manpages just an issue for cctools? | 20:20:50 |
| samasaur | like the API manpages are from the SDK an dseem like they were just rm'd | 20:21:04 |
| Randy Eckenrode | If any of the source releases have them, they’re usually included in the build. | 20:33:51 |
| samasaur | but for like. man write in a dev shell | 20:36:49 |
| samasaur | it looks in $DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man | 20:37:48 |
| samasaur | which doesn't exist in our current SDKs, but feels like it pretty easily could, since we download manpages as part of the SDK | 20:40:06 |
| samasaur | unless what's downloaded still needs to be built and that build requires llvm-manpages | 20:40:31 |
| samasaur | * unless what's downloaded still needs to be built and that build requires llvm-manpages? | 20:40:33 |
| Randy Eckenrode | No, they’re removed to limit what we’re distributing from the SDK to headers and stubs since those are arguably necessary for interoperability. Most of those man pages should be obtainable from the source releases. | 20:41:31 |
| Randy Eckenrode | We could possibly smuggle them in via the empty darwin.libSystem derivation. | 20:41:59 |
| 28 Nov 2025 |
| Randy Eckenrode | I’ve picked my Swift work back up. I’m trying to make the versioning of the LLVM fork more accurate to what Apple uses. The source is LLVM 19.1.5, but the version reported is 17.0.0. That’s probably going to make dealing with the overrides a lot of fun. | 16:27:47 |
| Randy Eckenrode | The new, scope-based LLVM is so much nicer to override. There’s still jank, but I don’t have to do anything to handle build vs. host vs. target packages.
(llvmPackages_19.override {
officialRelease = {
version = "19.1.5"; # From https://github.com/swiftlang/llvm-project/blob/swift-$swiftVersion-RELEASE/cmake/Modules/LLVMVersion.cmake
};
monorepoSrc = fetchFromGitHub {
owner = "swiftlang";
repo = "llvm-project";
tag = "swift-${lib.getVersion swift}-RELEASE";
hash = "sha256-DahdGT8VMBOXuwfhtXIJGFJmmhzzoQ6NdpU2CDs5B/s=";
};
otherSplices = generateSplicesForMkScope [
"swiftPackages"
"llvmPackages"
];
}).overrideScope
(
_: prev: {
version = "17.0.0"; # From https://github.com/swiftlang/swift/blob/swift-$swiftVersion-RELEASE/utils/build_swift/build_swift/defaults.py#L51
}
)
| 17:26:02 |
| Randy Eckenrode | * The new, scope-based LLVM is so much nicer to override. There’s still jank, but I don’t have to do anything to handle build vs. host vs. target packages.
let
swiftlangLlvmVersion = "17.0.0"; # From https://github.com/swiftlang/swift/blob/swift-$swiftVersion-RELEASE/utils/build_swift/build_swift/defaults.py#L51
llvmVersion = "19.1.5"; # From https://github.com/swiftlang/llvm-project/blob/swift-$swiftVersion-RELEASE/cmake/Modules/LLVMVersion.cmake
in
(llvmPackages_19.override {
officialRelease = { version = llvmVersion; };
monorepoSrc = fetchFromGitHub {
owner = "swiftlang";
repo = "llvm-project";
tag = "swift-${lib.getVersion swift}-RELEASE";
hash = "sha256-DahdGT8VMBOXuwfhtXIJGFJmmhzzoQ6NdpU2CDs5B/s=";
};
otherSplices = generateSplicesForMkScope [
"swiftPackages"
"llvmPackages"
];
}).overrideScope
(
_: prev: {
version = swiftlangLlvmVersion;
release_version = llvmVersion;
}
)
| 17:30:48 |
| Randy Eckenrode | The weird version overrides are because of the way LLVM captures the version. | 17:31:14 |
