Newest at the top
2024-11-01 15:25:03 +0100 | <merijn> | Not to mention GHC being able to use CPP macros as values |
2024-11-01 15:24:45 +0100 | <merijn> | Which can be helpful for your sanity |
2024-11-01 15:24:36 +0100 | <merijn> | mauke: GHC can automatically check whether your declared types match the headers |
2024-11-01 15:24:06 +0100 | <merijn> | \o/ |
2024-11-01 15:23:23 +0100 | <mauke> | oh hello, executable stripping works if I turn it on in ~/.cabal/config |
2024-11-01 15:22:46 +0100 | <mauke> | technically I could probably just delete the header files because I'm pretty sure ghc doesn't care anyway |
2024-11-01 15:22:44 +0100 | tired | (~tired@user/tired) tired |
2024-11-01 15:21:46 +0100 | <mauke> | I don't have generated files, so for me it's all "sdist" in a sense |
2024-11-01 15:20:00 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
2024-11-01 15:19:45 +0100 | <merijn> | runtime" to be one of the things preserving my sanity |
2024-11-01 15:19:39 +0100 | <merijn> | Docker makes sense when you remember that lots of ecosystems (looking at you npm, typescript, python, etc.) don't have a sane boundary to distinguish "necessary at build/packaging" from "necessary at runtime". And while I share your annoyance of "I need to set 4 fields in .cabal to packabe my headers" is annoying. I find the clear distinction between "what is sdist, what is build time, and what is |
2024-11-01 15:19:29 +0100 | vgtw | (~vgtw@user/vgtw) (Ping timeout: 248 seconds) |
2024-11-01 15:17:12 +0100 | <merijn> | Using docker the "right" way is for people who don't know how to build/package their own stuff :p |
2024-11-01 15:16:32 +0100 | <mauke> | which I then copy out to the host system |
2024-11-01 15:16:23 +0100 | <mauke> | right now I'm using docker "backwards" in that I have a custom build container just for creating CentOS 7 binaries |
2024-11-01 15:15:40 +0100 | <mauke> | "running on stupid machines" is very valid |
2024-11-01 15:15:17 +0100 | <merijn> | You can ignore that part on sane machine ;) |
2024-11-01 15:14:55 +0100 | <merijn> | basically |
2024-11-01 15:14:54 +0100 | <mauke> | I see |
2024-11-01 15:14:50 +0100 | <mauke> | ah, it's just a realpath reimplementation |
2024-11-01 15:14:44 +0100 | <merijn> | mauke: It's mostly "I was running on some stupidly broken machines" engineered |
2024-11-01 15:13:51 +0100 | <mauke> | wow, that scriptpath thing looks ... overengineered |
2024-11-01 15:13:10 +0100 | <merijn> | I dunno if adding library-stripping also work? |
2024-11-01 15:12:54 +0100 | <mauke> | cabal install with split sections and explicit executable-stripping: 11M |
2024-11-01 15:12:42 +0100 | <mauke> | cabal install with split sections: 18M |
2024-11-01 15:12:31 +0100 | <mauke> | cabal install with 'executable-stripping: True' in project file: 16M |
2024-11-01 15:12:20 +0100 | <merijn> | mauke: I also have this neat lazy people trick for testing "in-development" executables https://github.com/NLeSC-AAA2/etherpacket/blob/master/EtherPacket |
2024-11-01 15:12:04 +0100 | <mauke> | cabal install with default options: 25M |
2024-11-01 15:11:49 +0100 | <mauke> | final tally: |
2024-11-01 15:09:24 +0100 | <mauke> | given that it works fine as long as you don't sdist, which I have no intention of ever doing |
2024-11-01 15:08:50 +0100 | <mauke> | "broken" is debatable |
2024-11-01 15:07:58 +0100 | <tomsmeding> | right |
2024-11-01 15:07:55 +0100 | <merijn> | Which is good TM |
2024-11-01 15:07:54 +0100 | <tomsmeding> | (not saying that's a bad thing) |
2024-11-01 15:07:49 +0100 | <merijn> | tomsmeding: Which means it detects broken cabal configs ;) |
2024-11-01 15:07:36 +0100 | <tomsmeding> | except it goes through sdist |
2024-11-01 15:07:26 +0100 | <merijn> | tomsmeding: I mean, --install-method=copy --install-dir=foo does the same |
2024-11-01 15:07:12 +0100 | <merijn> | anyway, gotta get back to work |
2024-11-01 15:07:09 +0100 | <tomsmeding> | mauke: "I just want an executable" `cp $(cabal list-bin yourexename) wherever` |
2024-11-01 15:06:53 +0100 | <mauke> | ah, building 'encoding' now. that always takes forever |
2024-11-01 15:06:03 +0100 | <merijn> | I think I'd something like a 20x reduction in final binary size |
2024-11-01 15:05:18 +0100 | <merijn> | So it can (theoretically) lob off entire sections of your dependency graph if you use only a fraction of libraries with big dependency lists |
2024-11-01 15:05:03 +0100 | <mauke> | wasn't on before. rebuilding world now ... :-) |
2024-11-01 15:04:38 +0100 | <merijn> | split-sections causes GHC to put every top level export into it's own linker section, so that any moderately modern linker can include only the (transitive) symbols you actually use. Instead of linking every transitive dependency even if you don't use them |
2024-11-01 15:02:50 +0100 | <mauke> | if I delete tmp, comment out 'exectuable-stripping: True' in cabal.project, and rerun 'cabal install', I get a non-stripped file |
2024-11-01 15:02:39 +0100 | <merijn> | That will *massively* shrink your executable size (although it will mean having to rebuild the world :p) |
2024-11-01 15:02:05 +0100 | <merijn> | mauke: Also, if you're building executables for publishing: is `split-sections` on? |
2024-11-01 15:01:39 +0100 | <merijn> | not sure about that, though |
2024-11-01 15:01:34 +0100 | <merijn> | mauke: I don't think it will rebuild previously installs after you change the global config (whereas changes to cabal.project *WILL* force a rebuild) |
2024-11-01 15:00:59 +0100 | <merijn> | did you just enable it? |