HP 2015.2.0.0 and GHC 7.10

[Mateusz Kowalczyk]

On 03/27/2015 05:16 PM, Randy Polen wrote:
> I am helping Mark with the Haskell Platform, doing the Windows builds (32- and
> 64-bit).  I want you to be aware of a problem I am encountering, and solicit
> suggestions and possible help.
>  
> In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit
> yet but likely the same problem will occur), I seem to be hitting the 32K limit
> for the length of arguments to a process, encountered while cabal is invoking
> haddock to build the docs for the OpenGLRaw package.  For HP2014.2.0.0, the
> argument list was ~25K (from looking at my old build logs) but now is ~36K,
> which exceeds the maximum for CreateProcess (not a limit of the command-line,
> but of the OS call itself).
>  
> Is there a way to build haddock docs for a single package but in multiple
> haddock invocations (maybe building a .haddock file for portions, then
> combining them, with the goal that the command line is kept short)?  Seems this
> would also require a corresponding cabal change, as cabal is the invocator when
> this happens.
> 
> 
> Barring any existing mechanism, the typical solution to this problem on the
> Windows OS is (when possible, of course) to modify the program to accept a
> "response file" of command-line arguments.  In this case, we could add an
> option to haddock to accept either a complete "response file" (i.e., allowing
> *all* options and arguments to come from a file) or just a file containing the
> files to process.  Either of these changes to haddock are rather trivial to
> write (but adding another option implies more testing, documentation, other
> cases to handle, etc.).  Since haddock ships with the ghc release, that's
> another wrinkle for this particular release.  The other implication of such a
> solution is that cabal would need a change to utilize this change for it to be
> effective, checking haddock's version for support of this new haddock-flag, and
> either use it if the haddock version supports it, or do it optionally (which
> implies a new flag for cabal's haddock sub-command).  This change to cabal is
> also rather trivial to implement (this is not to imply insensitivity to the
> incurred cost of each line of code, nor to the added burden of user-visible
> changes such as a command-line option).
> 
> 
> (Less desirable possibilities, mentioned only for completeness: skip the
> documentation for OpenGLRaw for this version of the Haskell Platform; split up
> the OpenGLRaw package itself in some way.)
> 
> 
> Other possible solutions and work-arounds?  Thoughts on either using haddock in
> a different way (and the cabal change that would be required to break up the
> doc build into multiple steps for a single package)?  Thoughts on the "response
> file" solution?
> 

Hi Randy,

We actually have an issue about response files already[1], I just
haven't gotten around to doing it. When I looked into it last, cabal
folks were willing to support it too so there should be no problem on
that end. All that remains is that we write code for it in Haddock and
for cabal and GHC to adapt. I can implement this in Haddock even today
and you can cherry-pick a patch onto whatever you're working with.

Is that satisfactory?

[1]: https://github.com/haskell/haddock/issues/285


-- 
Mateusz K.