| 23 Dec 2024 |
 Whovian9369 | On prerelease and git I'm only doing --replace-fail '{chash:8}' "${substring 0 8 src.rev}" which I'm pretty confident aren't going to mis-match at all even between updates.
(If those change at all, like if one gets removed, I'm sure that I'll figure it out pretty easily and add it to the extensive file list.) | 04:10:32 |
| 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 |
