Am 27.04.20 um 23:43 schrieb Henning Thielemann:

...

So my next thought is: "Let's just put it on Stackage, because the best days of Hackage seem to be over...". However, I cannot do that, because my project needs to compile on Hackage in order to be put on Stackage...

You only need to _release_ your package on Hackage, it is not required that the Hackage server can build it. Stackage builds packages on its own.

If Hackage fails to build your documentation, you can create it yourself and upload it manually:

$ cabal haddock --for-hackage --hyperlink-source $ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz

Thanks Henning, this was helpful for me as well. I just uploaded the docs for darcs-2.14.3 using your recipe. Note however that for newer cabal-install versions the option names have changed to --haddock-for-hackage and --haddock-hyperlink-source. Cheers Ben

By the way, I just failed building the documentation. This is all wrong :|. Resolving dependencies... Build profile: -w ghc-8.8.3 -O1 In order, the following will be built (use -v for more details): - matrices-0.5.0 (lib) (requires build) - storable-complex-0.2.3.0 (lib:storable-complex) (requires build) - hmatrix-0.20.0.0 (lib) (requires build) - elynx-tools-0.2.2 (lib) (first run) Starting storable-complex-0.2.3.0 (all, legacy fallback) Starting matrices-0.5.0 (lib) Building storable-complex-0.2.3.0 (all, legacy fallback) Building matrices-0.5.0 (lib) Failed to build matrices-0.5.0. Build log ( /home/dominik/.cabal/logs/ghc-8.8.3/matrices-0.5.0-fad3378ef6f4b9b628fbbd797b7c85b4d66179cdfbce76fdac9c0e095f6cd439.log ): Configuring library for matrices-0.5.0.. Preprocessing library for matrices-0.5.0.. Building library for matrices-0.5.0.. [ 1 of 13] Compiling Data.Matrix.Class.Mutable ( src/Data/Matrix/Class/Mutable.hs, dist/build/Data/Matrix/Class/Mutable.o ) src/Data/Matrix/Class/Mutable.hs:10:1: error: Could not find module ‘Control.Monad.Primitive’ There are files missing in the ‘primitive-0.7.0.1’ package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 10 | import Control.Monad.Primitive (PrimMonad, PrimState) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ src/Data/Matrix/Class/Mutable.hs:11:1: error: Could not find module ‘Data.Vector.Generic.Mutable’ There are files missing in the ‘vector-0.12.1.2’ package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 11 | import qualified Data.Vector.Generic.Mutable as GM | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Dominik Schrempf writes:

Thank you, I also didn't know that a package release is enough to be added to Stackage. I was also not aware of the cabal commands creating the documentation for Hackage.

Nevertheless, I believe that we should improve on developer-friendliness. In the end, we --- the developers and users --- create and maintain the libraries and the ecosystem, and we depend on a healthy Haskell ecosystem.

Dominik

Ben Franksen writes:

...

Am 27.04.20 um 23:43 schrieb Henning Thielemann:

...

...

So my next thought is: "Let's just put it on Stackage, because the best days of Hackage seem to be over...". However, I cannot do that, because my project needs to compile on Hackage in order to be put on Stackage...

You only need to _release_ your package on Hackage, it is not required that the Hackage server can build it. Stackage builds packages on its own.

If Hackage fails to build your documentation, you can create it yourself and upload it manually:

$ cabal haddock --for-hackage --hyperlink-source $ cabal upload --documentation --publish dist/pkg-0.1-docs.tar.gz

Thanks Henning, this was helpful for me as well. I just uploaded the docs for darcs-2.14.3 using your recipe.

Note however that for newer cabal-install versions the option names have changed to --haddock-for-hackage and --haddock-hyperlink-source.

Cheers Ben

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Tue, 28 Apr 2020, Ben Franksen wrote:

Today I ran again into a problem I had several times before: compiling Cabal-3.2.* (the library) with ghc-8.2.2 and cabal with default options (including jobs: $ncpu, though it actually used only one cpu) eats all the memory on my machine (8GB, but I had a tor browser and another browser and thunderbird running) so that it completely freezes (no mouse, no keyboard). Had to reboot using sysrq escape hatch. Not funny. I think this is due to use of ghc --make and some very large modules. Thankfully memory use has improved with later ghc versions.

That's why I never use 'jobs: $ncpu' and also oppose to use this as the default setting. [1] There are some modules in packages that frequently eat up all my resources, e.g. I know that building "Cabal the library" is such a package. I remember that I can save memory by aborting compilation and restart it. It seems that GHC may cache too much. But continuing an aborted compilation is not possible for imported packages when using 'cabal install'. Other packages contain big modules automatically created by Template Haskell. [1] https://github.com/haskell/cabal/issues/5776

On Tue, 28 Apr 2020, Ben Franksen wrote:

Am 28.04.20 um 14:12 schrieb Henning Thielemann:

...

[1] There are some modules in packages that frequently eat up all my resources, e.g. I know that building "Cabal the library" is such a package. I remember that I can save memory by aborting compilation and restart it. It seems that GHC may cache too much. But continuing an aborted compilation is not possible for imported packages when using 'cabal install'. Other packages contain big modules automatically created by Template Haskell.

Yes. In the past I also had difficulty with vector and with aeson.

I remember those, too.

On Tue, 28 Apr 2020 at 08:13, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Tue, 28 Apr 2020, Ben Franksen wrote:

...

I remember that I can save memory by aborting compilation and restart it. It seems that GHC may cache too much.

I've also experienced this multiple times (e.g., with Qt, which is huge, and with yesod apps). Could this also be indicative of a leak? I sometimes wonder if the developers behind some libraries operate with resources that are far beyond what any of us have or can afford. Ivan

On Tue, 28 Apr 2020, Dominik Schrempf wrote:

By the way, I just failed building the documentation. This is all wrong :|.

Resolving dependencies... Build profile: -w ghc-8.8.3 -O1 In order, the following will be built (use -v for more details): - matrices-0.5.0 (lib) (requires build) - storable-complex-0.2.3.0 (lib:storable-complex) (requires build) - hmatrix-0.20.0.0 (lib) (requires build) - elynx-tools-0.2.2 (lib) (first run) Starting storable-complex-0.2.3.0 (all, legacy fallback) Starting matrices-0.5.0 (lib) Building storable-complex-0.2.3.0 (all, legacy fallback) Building matrices-0.5.0 (lib)

Failed to build matrices-0.5.0. Build log ( /home/dominik/.cabal/logs/ghc-8.8.3/matrices-0.5.0-fad3378ef6f4b9b628fbbd797b7c85b4d66179cdfbce76fdac9c0e095f6cd439.log ): Configuring library for matrices-0.5.0.. Preprocessing library for matrices-0.5.0.. Building library for matrices-0.5.0.. [ 1 of 13] Compiling Data.Matrix.Class.Mutable ( src/Data/Matrix/Class/Mutable.hs, dist/build/Data/Matrix/Class/Mutable.o )

src/Data/Matrix/Class/Mutable.hs:10:1: error: Could not find module ‘Control.Monad.Primitive’ There are files missing in the ‘primitive-0.7.0.1’ package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 10 | import Control.Monad.Primitive (PrimMonad, PrimState) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What cabal-install version did you use for this build and what 'build' method did you use, v1-build or v2-build? The message could mean that you are building with profiling but some 'primitive' was installed without profiling. With 'cabal v2-build' (new-build) there should not be a problem, because Cabal should simply build profiling objects when needed. However, for building the documentation you do not need profiling. But then again, profiling was just a guess. It's best you show us your actual command-line and used Cabal version and the package (e.g. repository) that you try to upload.

Am 28.04.20 um 15:38 schrieb Dominik Schrempf:

Maybe I should have been more specific. I can compile the package with `stack build`, but never built with cabal directly.

My cabal versions are: + cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.1.0 of the Cabal library

The command I use is cabal build or cabal haddock --haddock-for-hackage --haddock-hyperlink-source

v2-build and new-build fail with the error I posted below.

By default cabal uses the ghc that it finds in your PATH. My guess is that this is a different version than that in your stack setup, which means cabal may select some older or newer dependencies as a result. If you have the same ghc, you could look at the versions of the libraries that cabal selects and that give you trouble. Compare them to what your working stack setup uses and adapt the version bounds accordingly in your cabal file. Or perhaps stack can be convinced to write a cabal file that freezes the versions to exactly the set supported by that setup? Cheers Ben