| 24 Dec 2024 |
 6pak | GGG replied to your question about buildPackages | 00:56:32 |
| 6pak | if after reading the link you are still confused, don't worry, I think everyone is | 00:56:42 |
| 6pak | imo the mess comes from the implicit splicing mechanic, it would be much clearer if you were forced to explicitly reference the package set but oh well | 00:57:54 |
 GGG | Huh, I thought `hostPlatform` was already the machine it's being built on | 01:00:43 |
| 6pak | hostPlatform is the host that will run the package | 01:01:04 |
| 6pak | buildPlatform is the host that is building the package | 01:01:17 |
| 6pak | targetPlatform is a special thing for target-specific packages, like the GCC compiler | 01:01:43 |
| 6pak | because you can build a GCC compiler on linux-x64 (buildPlatform) that will run on linux-arm64 (hostPlatform) that compiles binaries for linux-riscv (targetPlatform) | 01:02:38 |
| 6pak | so in most cases hostPlatform == targetPlatform | 01:02:52 |
| 6pak | in nixpkgs I think it's only GCC that uses targetPlatform? | 01:03:22 |
| GGG | God, this is so confusing | 01:03:34 |
| 6pak | llvm/clang can compile to multiple targets from single binary just fine | 01:03:35 |
| GGG | I think I get it now though | 01:04:11 |
| GGG | But yeah, most packages just outright don't work with cross from what I'm understanding then | 01:04:24 |
| 6pak | yup and add the fact that nativeBuildInputs/buildInputs silently use a hidden cursed splicing method that "convert" the package to a different platform set | 01:04:30 |
| 6pak | which is why a lot of build scripts in nixpkgs are broken | 01:04:42 |
| 6pak | because people are used to adding a binary to nativeBuildInputs of a setup hook or something and it working | 01:04:56 |
| GGG | Since I pretty much never see `pkgsBuildHost`/`buildPackages` being used | 01:05:04 |
| 6pak | and then they embed a package into a script literal in the same way and it breaks | 01:05:07 |
| 6pak | most packages don't have a lot of custom logic so they work finel | 01:05:45 |
| 6pak | * most packages don't have a lot of custom logic so they work fine | 01:05:47 |
| 6pak | and the mobile nixos[*] project put a lot of effort to make it work | 01:05:58 |
| 6pak | so most native stuff works | 01:06:01 |
| GGG | Issue is that there's no way to easily specify what should be taken from pkgsBuildHost and pkgsHostTarget | 01:06:27 |
| GGG | I don't like that it becomes less declarative | 01:06:49 |
| GGG | `{ buildPackages }` instead of `{ dotnet-sdk_9, makeWrapper, ... }` | 01:07:40 |
| GGG | But I guess there's no way around it | 01:07:51 |
| GGG | Thanks for the explanation though, it was something I never really considered | 01:08:08 |
| 6pak | I mean for add-nuget-deps the better solution is to make a fetch-deps.nix | 01:11:14 |
| 6pak | and do buildPackages.callPackage fetch-deps.nix {} | 01:11:24 |
