From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: For a slimmer GHC Date: Mon, 2 Nov 2015 12:23:42 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZtDDE-00026d-Tf for guix-devel@gnu.org; Mon, 02 Nov 2015 06:23:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZtDDD-0002ll-A4 for guix-devel@gnu.org; Mon, 02 Nov 2015 06:23:44 -0500 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: ludo@gnu.org Cc: Guix-devel ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Hello! > > GHC is insanely large, 1.2G for its closure, most of which is itself: > > store item total = self > /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2 1209.7 = 860.5 71.1% > /gnu/store/k6r37137lfpg3l3igi50c7lj2za7kqly-ld-wrapper-0 153.7 = 0.0 0.0% > /gnu/store/czs63sm4l0s4a56ab38dqvkx19yzylbq-perl-5.16.1 141.2 = 49.2 4.1% > /gnu/store/hddjjpkfvwaf1j1q3qwpvby0rid3k8by-gcc-4.9.3 138.1 = 77.3 6.4% > /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc 120.2 = 42.6 3.5% > /gnu/store/fmxxkrpwajcnb9cyncgh4f4z6ybknl1g-guile-2.0.11 109.0 = 16.1 1.3% > /gnu/store/y5psndwpbbkjrf856x757psb708y62dn-binutils-2.25.1 82.5 = 44.6 3.7% > /gnu/store/mnwjrkbfzkb5ifhqf8hssf3cxfvg11l6-coreutils-8.24 77.8 = 13.8 1.1% > /gnu/store/fzp98iyq7a2i4d4siw0ab0y0wa95vv8k-readline-6.3 68.6 = 1.2 0.1% > > [...] > > $ du -ms /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/ > 871 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/ > $ du -ms /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7= .10.2/ > 871 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.1= 0.2/ > > The main problem is that, for each module, we have three variants: > > $ du -ms /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/gh= c-7.10.2/trans_3eG64VdP2vzGjP6wJiCp5X/* > 3 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.= 2/trans_3eG64VdP2vzGjP6wJiCp5X/Control > 1 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.= 2/trans_3eG64VdP2vzGjP6wJiCp5X/Data > 5 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.= 2/trans_3eG64VdP2vzGjP6wJiCp5X/libHStransformers-0.4.2.0-3eG64VdP2vzGjP6wJi= Cp5X.a > 2 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.= 2/trans_3eG64VdP2vzGjP6wJiCp5X/libHStransformers-0.4.2.0-3eG64VdP2vzGjP6wJi= Cp5X-ghc7.10.2.so > 7 /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.= 2/trans_3eG64VdP2vzGjP6wJiCp5X/libHStransformers-0.4.2.0-3eG64VdP2vzGjP6wJi= Cp5X_p.a > > What about removing all the .a? Would that be OK? > > On that topic I found > but it=E2=80=99s= not > clear to me whether this is relevant here. At worst we can add a phase > that removes these files. I do not know much about this topic, but I think that the discussion at the link you provided is relevant, as probably is the one at https://ghc.haskell.org/trac/ghc/wiki/DynamicLinkingDebate My interpretation of the above discussions is that it is in principle OK to remove statically linked libraries, but: (i) you loose the possibility to create statically linked executables (the default; the discussion here is about Haskell libraries, not system libraries), (ii) dynamically linked executables are slower than statically linked ones and (iii) it may create some build systems compatibility problems. Personally I would keep them as the above discussions give me the impression that dynamic linking is not very mature in GHC. In any case, if people feel strongly about removing static libraries, then I would at least add an option to the build-system to easily re-enable their creation. > > A secondary issue is documentation: There=E2=80=99s a =E2=80=9Cdoc=E2=80= =9D output, but > =E2=80=98ghc:out=E2=80=99 depends on =E2=80=98ghc:doc=E2=80=99: > > $ guix gc --references /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.= 10.2/ | grep doc > /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc > $ du -ms /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc > 47 /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc > $ grep -r r539jrq7jk9vkmm1255i5jqs7skn4fag /gnu/store/1iwl222h2qw80fyr= 578sdjdki0pbcjm0-ghc-7.10.2 > /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/pac= kage.conf.d/process-1.2.3.0-f0287ac288afc0705be775d1adda59ee.conf:haddock-i= nterfaces: /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share= /doc/ghc/html/libraries/process-1.2.3.0/process.haddock > /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/pac= kage.conf.d/process-1.2.3.0-f0287ac288afc0705be775d1adda59ee.conf:haddock-h= tml: /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/g= hc/html/libraries/process-1.2.3.0 > /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/pac= kage.conf.d/Cabal-1.22.4.0-43c3ae30d75ac742e521d26b63721876.conf:haddock-in= terfaces: /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/= doc/ghc/html/libraries/Cabal-1.22.4.0/Cabal.haddock > /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/pac= kage.conf.d/Cabal-1.22.4.0-43c3ae30d75ac742e521d26b63721876.conf:haddock-ht= ml: /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/gh= c/html/libraries/Cabal-1.22.4.0 > > Any idea if we could avoid references to the =E2=80=9Cdoc=E2=80=9D output= in these > *.conf files? For instance, if there=E2=80=99s a variable like, say, > =E2=80=98HADDOCK_PATH=E2=80=99, we can certainly remove the hardcoded ref= erences As far as I understand, these full paths entries in .conf files are used to generate links in the HTML documentation. As one example, when you generate the documentation for the 'ghc-mtl' package, the generated documentation includes links, e.g., to the documentation of the 'identity' function which resides in another package. I believe that the location of the latter is retrieved from the .conf files. Browsing the Haddock documentation I do not see environment variables https://www.haskell.org/haddock/doc/html/invoking.html Regards, Fede