Make --no-tmp-comp-dir the default
Since Haddock uses GHC's no-code backend, using a temp directory for compilation results doesn't make sense anymore. Especially since it prevents reading of existing interface files and always triggers recompilation. This MR makes --no-tmp-comp-dir the default behavior and introduces a --tmp-comp-dir flag that reverts to the old default, just in case anyone needs it for some reason.
Merge request reports
Activity
assigned to @FinleyMcIlwaine
@FinleyMcIlwaine This is quite interesting. Would you mind explaining a bit how the sentence "Haddock uses GHC's no-code backend" interacts with "Haddock reads information from .hi files"? Upon a naïve read I would think they are quite opposite, so certainly I am missing some crucial element here.
Edited by Hécate KleidukosSure! The no-code backend means (imprecisely, for our purposes) that no compilation result files (.hi, .hie, .o, etc.) will be written by GHC default. So the phrase "Haddock uses GHC's no-code backend" just means that running Haddock will not result in any GHC compilation files being written/overwritten, unless a flag is passed via
--optghcthat overrides this behavior (e.g.-fwrite-interface).That being said, Haddock still needs the module interfaces stored in .hi files (at a minimum) to generate documentation, so it calls GHC's
load'function to retrieve them, which will either find existing .hi files on disk to read the interfaces from, or it will recompile the given source modules just far enough to generate the interfaces (not generating code).This is why we shouldn't run the GHC session in a temporary directory by default. All it does is hide any existing build results from us and cause recompilation. The conventional benefit of temporary directories preventing any overwriting of existing build results or hiding unwanted results does not apply, since Haddock doesn't write any compilation results by default.
Let me know if that helps clear it up at all!
-
Yes this is very helpful, thank you very much. Please feel free to ping @haddock in order to involve the (newly reformed) Haddock team. :)
I have a companion MR on Cabal that greatly improves the recompilation avoidance behavior for documentation generation, and it handles the renamed
--libflag by passing--resources-dirif the Haddock version is >= 2.29.0 and--libotherwise. So it is crucial, once that is merged, that this MR is only included in Haddock >= 2.29.Should I bump the version as part of this MR?
added 2 commits
