Re: For a slimmer GHC

[Ludovic Courtès]

Federico Beffa <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:

[...]

>> 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.

(i) and (ii) apply to all the packages in Guix, not just Haskell
packages: most of the time we provide only shared libraries, and PIC
code includes a slight “performance penalty” (and possibly large memory
savings if several processes use the library.)

I’m not sure what (iii) means though?

> 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.

I think we could even simply move them to a different output, for those
who really need them.

>> 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

OK, too bad.

Thanks for your feedback!

Ludo’.