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 <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
