Sender | Message | Time |
---|---|---|
31 Oct 2024 | ||
when I got the latest version of utf-8-validate to build by itself, adding libtool to the buildInputs made it stop doing this, it seems | 20:16:10 | |
i can't even tell if the upstream dep is busted at 5.0.10 or if it's darwin sdk fuckery that might be fixed on master as of this morning | 20:16:12 | |
the conditions in binding.gyp seem more sophisticated in that latest version than in some others that appear in the tree | 20:16:48 | |
utf-8-validate is a dependency of @wessberg/ts-evaluator as well but I don't see it in my node_modules when debugging with nix-shell | 20:17:23 | |
doesn't look particularly SDK-refactor-related but I strongly encourage rebasing on current master all the same | 20:17:27 | |
* utf-8-validate is a dependency of @wessberg/ts-evaluator as well but I don't see it in my node_modules when debugging with nix-shell /nix develop | 20:17:29 | |
In reply to @pxc:matrix.orgsophistication isn't what changed. it's that they stopped building "fat" binaries with both x86_64 and aarch64 object code in them at the same time | 20:17:51 | |
here's the old version: https://pastebin.com/XDxvjsgs | 20:18:36 | |
yeah | 20:18:37 | |
10.7 deployment target, nice | 20:18:53 | |
yeah the logs emitted a warning about that but I have no intuitions about whether it's meaningful | 20:19:21 | |
shouldn't matter | 20:19:54 | |
current questions:
| 20:22:58 | |
build still fails on master because of missing perl , I'm a dingus. Lemme pull master into my local checkout with that fix instead | 20:23:53 | |
yeah, Darwin SDK changes on master don't seem to affect it | 20:28:02 | |
In reply to @pxc:matrix.org
| 20:28:12 | |
In reply to @pxc:matrix.orgi did actually make a shellHook for buildNpmPackage packages to make that sort of check work, but i'm not contributing to nixpkgs anymore so oh well i guess | 20:29:51 | |
that sucks, but I understand | 20:30:32 | |
it looks like utf-8-validate appears multiple times in the dependency tree, and at least once as just a first-order dependency (and not a devDependency ). Are you sure they're all eliminable | 20:31:31 | |
i'd give snippet for disabling optional peer deps in npmInstallFlags or whatever it is, but i'm on mobile rn sadly | 20:31:33 | |
ty! | 20:31:43 | |
In reply to @pxc:matrix.orgall of the old ones that still try to build fat executables are from optional peer deps from microsoft etc pinning an ancient version of ws for some godawful reason | 20:33:01 | |
so they don't have to be all eliminable | 20:33:23 | |
got it | 20:33:32 | |
In reply to @lily:lily.flowers this was enough for me to find the flag and plenty of examples in Nixpkgs, if the flag was but this package already used that, and unlike the version I had building as part of | 20:47:37 | |
In reply to @lily:lily.flowers* this was enough for me to find the flag and plenty of examples in Nixpkgs, if the flag was but this package already used that, and unlike the version I had building as part of | 20:47:57 | |
In reply to @pxc:matrix.orgoh then take that out. i was wondering why it would be including peer deps at all without that flag | 20:48:27 | |
legacy-peer-deps does the opposite of what i suggested | 20:48:44 | |
by overeagerly including them | 20:48:55 | |
I thought it was the other way around at any rate, removing it made no difference :( | 20:53:33 |