HP 2015.2.0.0 and GHC 7.10

[Randy Polen]

Mateusz,


Haddock issue #285 indeed sounds like a win (or Win-dows).


A logistical wrinkle I worry about for the short-term is that

the HP uses the GHC release, and haddock is part of that release.  I can certainly

incorporate a newer haddock, but I want to mention this GHC-related release

issue in case others here have a better approach for this part of the plan (e.g.,

"yes, go ahead and augment GHC 7.10.1 release with a custom haddock" or

"no, let's spin up a 7.10.1.1 (?)").


There is also the Cabal piece as well, but that is separate from GHC and thus

a bit easier to incorporate into the HP build.


Randy

----------------------------------------
> Date: Sat, 28 Mar 2015 15:12:34 +0000
> From: fuuzetsu at fuuzetsu.co.uk
> To: ghc-devs at haskell.org
> Subject: Re: HP 2015.2.0.0 and GHC 7.10
>
> 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.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150328/8bcbb3b1/attachment.html>