HP 2015.2.0.0 and GHC 7.10

[Edward Kmett]

To ship `gl`, we wound up having to rename all of the modules to make it
work on Windows.

Alas, the module name conventions used by `OpenGLRaw` are longer.

-Edward



On Fri, Mar 27, 2015 at 1:16 PM, Randy Polen <randyhaskell at outlook.com>
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?
>
>
> Randy
> _______________________________________________
> 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/20150327/fa174b04/attachment-0001.html>