<div dir="ltr">To ship `gl`, we wound up having to rename all of the modules to make it work on Windows.<div><br></div><div>Alas, the module name conventions used by `OpenGLRaw` are longer.</div><div><br></div><div>-Edward<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 1:16 PM, Randy Polen <span dir="ltr"><<a href="mailto:randyhaskell@outlook.com" target="_blank">randyhaskell@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am helping Mark with the Haskell Platform, doing the Windows builds (32- and<br>
64-bit).  I want you to be aware of a problem I am encountering, and solicit<br>
suggestions and possible help.<br>
<br>
In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit<br>
yet but likely the same problem will occur), I seem to be hitting the 32K limit<br>
for the length of arguments to a process, encountered while cabal is invoking<br>
haddock to build the docs for the OpenGLRaw package.  For HP2014.2.0.0, the<br>
argument list was ~25K (from looking at my old build logs) but now is ~36K,<br>
which exceeds the maximum for CreateProcess (not a limit of the command-line,<br>
but of the OS call itself).<br>
<br>
Is there a way to build haddock docs for a single package but in multiple<br>
haddock invocations (maybe building a .haddock file for portions, then<br>
combining them, with the goal that the command line is kept short)?  Seems this<br>
would also require a corresponding cabal change, as cabal is the invocator when<br>
this happens.<br>
<br>
<br>
Barring any existing mechanism, the typical solution to this problem on the<br>
Windows OS is (when possible, of course) to modify the program to accept a<br>
"response file" of command-line arguments.  In this case, we could add an<br>
option to haddock to accept either a complete "response file" (i.e., allowing<br>
*all* options and arguments to come from a file) or just a file containing the<br>
files to process.  Either of these changes to haddock are rather trivial to<br>
write (but adding another option implies more testing, documentation, other<br>
cases to handle, etc.).  Since haddock ships with the ghc release, that's<br>
another wrinkle for this particular release.  The other implication of such a<br>
solution is that cabal would need a change to utilize this change for it to be<br>
effective, checking haddock's version for support of this new haddock-flag, and<br>
either use it if the haddock version supports it, or do it optionally (which<br>
implies a new flag for cabal's haddock sub-command).  This change to cabal is<br>
also rather trivial to implement (this is not to imply insensitivity to the<br>
incurred cost of each line of code, nor to the added burden of user-visible<br>
changes such as a command-line option).<br>
<br>
<br>
(Less desirable possibilities, mentioned only for completeness: skip the<br>
documentation for OpenGLRaw for this version of the Haskell Platform; split up<br>
the OpenGLRaw package itself in some way.)<br>
<br>
<br>
Other possible solutions and work-arounds?  Thoughts on either using haddock in<br>
a different way (and the cabal change that would be required to break up the<br>
doc build into multiple steps for a single package)?  Thoughts on the "response<br>
file" solution?<br>
<br>
<br>
Randy<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>