Closed mayfield closed 2 years ago
MarshallOfSound
commented
2 years ago Instead of adding special handling for various "stray" file types I think we should keep the error that occurs with these files.
In this case the "correct" thing to do is to delete / not copy these .a files when packaging. Having this tool implicitly leave one of them around when they are different is semantically incorrect behavior.
mayfield
commented
2 years ago Via package.json -> build -> files ["!...../foo.a"] ?
I'm not familiar with all the exclusionary techniques available. Or does sqlite3 need to make changes?
It's worth noting that a non universal electron app will hapily let you include all the stray files you can come up with, and there are a LOT of dead files in a typical Electron app IME.
But I take your point. It does feel tedious to try and learn what all the non-binary types are. I just don't know a better way to dance around my builds not working.
MarshallOfSound
commented
2 years ago It's worth noting that a non universal electron app will hapily let you include all the stray files you can come up with, and there are a LOT of dead files in a typical Electron app IME.
Sure, the whole point is that a universal build of an app needs to somehow reconcile every single file in both architectures and somehow merge them. We can't teach universal about every possible file type so instead we insist that the developers handle these stray files themselves.
Via package.json -> build -> files ["!...../foo.a"] ?
We neither support nor recommend electron-builder so I have no idea how to do this over there 🤷 Officially supported Electron tooling consists of electron-packager / electron-forge, et. al
Some native packages like sqlite3 and cap leave various .a static archives around and universal was treating them like PLAIN files.