Hi Ludo, > In the meantime, our best workaround to reduce memory consumption is… to > split large files into smaller ones. Per M-x guix-locations, the > candidates are: > > gnu/packages/python.scm 986 > gnu/packages/perl.scm 401 > gnu/packages/haskell.scm 348
[…] > I think we could focus on the first two or three files. FTR, compiling > bioinformatics.scm peaks at ~500 MiB resident on x86_64. > > Ricardo, WDYT? I was hoping we could avoid this, but whatever: let’s do this :) > If we do this, do we split arbitrarily? Like the second half of > python.scm goes to python-cont.scm (provided there are no cross > top-level references)? Or do you have a better idea? Ultimately, I’d like to move packages to locations where they could permanently live, but that would probably take longer. Would it make sense to move all the python2-* packages to a new module? This would make the split rather simple and users wouldn’t have to remember which of their packages ended up in which half of the modules. It also means that we probably won’t have to mess with the copyright headers. For perl.scm I have no good ideas. Let’s split it up at an arbitrary point. For haskell.scm I’d begin by moving the following packages away: - check.scm: ghc-tasty*, ghc-quickcheck*, ghc-test*, ghc-hunit*, hspec*, ghc-hspec*, … - web.scm: ghc-tagsoup, ghc-cookie, ghc-http*, ghc-wai*, ghc-json, ghc-warp*, ghc-multipart, ghc-aeson* - crypto.scm: ghc-tf-random, ghc-digest, ghc-cryptonite, ghc-x509*, ghc-asn1*, ghc-pem, ghc-cryptohash*, ghc-entropy, ghc-crypto-api*, ghc-puremd5 - tls.scm: ghc-tls Maybe that’s enough already. Does that seem like a good idea? I could prepare patches for splitting up haskell.scm. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
