For a slimmer GHC

[Federico Beffa]

address@hidden (Ludovic Courtès) 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.10.2/
>
> The main problem is that, for each module, we have three variants:
>
> $ du -ms    
> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-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-3eG64VdP2vzGjP6wJiCp5X.a
> 2    
> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/trans_3eG64VdP2vzGjP6wJiCp5X/libHStransformers-0.4.2.0-3eG64VdP2vzGjP6wJiCp5X-ghc7.10.2.so
> 7    
> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/trans_3eG64VdP2vzGjP6wJiCp5X/libHStransformers-0.4.2.0-3eG64VdP2vzGjP6wJiCp5X_p.a
>
> What about removing all the .a?  Would that be OK?
>
> On that topic I found
> <https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault> but it’s 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’s a “doc” output, but
> ‘ghc:out’ depends on ‘ghc:doc’:
>
> $ 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/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2
> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/process-1.2.3.0-f0287ac288afc0705be775d1adda59ee.conf:haddock-interfaces:
>  
> /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/package.conf.d/process-1.2.3.0-f0287ac288afc0705be775d1adda59ee.conf:haddock-html:
>  
> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/ghc/html/libraries/process-1.2.3.0
> /gnu/store/1iwl222h2qw80fyr578sdjdki0pbcjm0-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/Cabal-1.22.4.0-43c3ae30d75ac742e521d26b63721876.conf:haddock-interfaces:
>  
> /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/package.conf.d/Cabal-1.22.4.0-43c3ae30d75ac742e521d26b63721876.conf:haddock-html:
>  
> /gnu/store/r539jrq7jk9vkmm1255i5jqs7skn4fag-ghc-7.10.2-doc/share/doc/ghc/html/libraries/Cabal-1.22.4.0
>
> Any idea if we could avoid references to the “doc” output in these
> *.conf files?  For instance, if there’s a variable like, say,
> ‘HADDOCK_PATH’, we can certainly remove the hardcoded references

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