Nix + dotnet | 118 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Dec 2024 | ||
| * lts uses 3.1.5, prerelease uses 7.0.1 | 00:53:01 | |
| the ef6 reference is just for decoration I guess | 00:53:23 | |
| Ah, I was looking at `pname = "EntityFramework"; version = "6.4.4"` | 00:53:47 | |
| I'm not familiar with these packages at all. I also don't remember what happened when it was left targeting netcoreapp3.1. that should be possible with a newer sdk, right? | 00:54:53 | |
| I'll see if I can play around with any of this at some point. Thank you both so much for the thoughts! | 01:05:25 | |
So this worked!
| 03:50:00 | |
(I removed a bunch from patchPhase for the above example) | 03:53:18 | |
I'd recommend using patch files whenever possible instead of substituteInPlace | 03:58:38 | |
| but if you've ensured that it only changes the versions of what you want then it should be fine | 03:59:01 | |
| That's a good tip, thanks | 03:59:59 | |
As far as I can tell, the only things that I'm changing are what I intend to, so I should be good. | 04:01:22 | |
(Honestly I just prefer substituteInPlace since it leaves a cleaner directory, but honestly I should just use patch files instead since that will make the actual derivation cleaner.) | 04:02:14 | |
| I myself prefer patch files because they ensure that things break if the file isn't the same anymore | 04:02:34 | |
| instead of just possibly silently changing things they shouldn't | 04:02:47 | |
| That's certainly a good point. Most of what I'm modifying (other than this) are hard to mis-patch so I'm not really worried, but hey that is still a very good reminder. https://github.com/Whovian9369/aaru-nix-flake/blob/620ef8866395544b5aad55b7dac83fa63a988731/lts.nix#L36-L79 | 04:07:20 | |
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 | ||
| GGG replied to your question about buildPackages | 00:56:32 | |
| if after reading the link you are still confused, don't worry, I think everyone is | 00:56:42 | |
| 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 | |
| Huh, I thought `hostPlatform` was already the machine it's being built on | 01:00:43 | |
| hostPlatform is the host that will run the package | 01:01:04 | |
| buildPlatform is the host that is building the package | 01:01:17 | |
| targetPlatform is a special thing for target-specific packages, like the GCC compiler | 01:01:43 | |
| 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 | |
| so in most cases hostPlatform == targetPlatform | 01:02:52 | |
| in nixpkgs I think it's only GCC that uses targetPlatform? | 01:03:22 | |
| God, this is so confusing | 01:03:34 | |
| llvm/clang can compile to multiple targets from single binary just fine | 01:03:35 | |
| I think I get it now though | 01:04:11 | |
| But yeah, most packages just outright don't work with cross from what I'm understanding then | 01:04:24 | |