| Age | Commit message (Collapse) | Author |
|---|
|
gitit is not yet compatible with GHC 8.6 yet. While that is being
fixed, this is a temporary workaround.
|
|
|
|
This way, the build() part will no longer require an Internet
connection. It also effectively freezes the sources of all dependencies
other a few boot libraries, improving reproducibility.
|
|
|
|
For now, we avoid parsec 3.1.12.0 until incompatibility is fixed. See:
https://github.com/jgoerzen/missingh/issues/42
https://github.com/haskell/parsec/issues/88
|
|
|
|
- Force Pandoc >= 1.19.2.2 because lower versions are broken for Cabal 2.0
( https://github.com/jgm/pandoc/issues/3876 )
- Source from Hackage, which also provides us a unique tarball name
- Enable --force-reinstalls
|
|
Switching back to cabal due to a bug in stack (see jgm/gitit#599 and
commercialhaskell/stack/#848 ) that's impossible to cleanly work around.
A local .cabal/config file is used to avoid contamination from the
user's ~/.cabal/config file. ghc-pristine prevents trouble caused by
the haskell-* packages, which lack the static libraries we need (that
was the original reason we switched to stack).
The presence of data files complicates this a lot: while "cabal copy"
does copy the data files of gitit, it doesn't copy the data files of
other dependent libraries (e.g. filestore). Therefore, we need to copy
all the data files straight from the .cabal-sandbox. To avoid conflicts
with other packages, we namespace all the data files under
/usr/share/gitit. And to avoid copying the docs, we re-override docdir
to something else. Cabal still installs the man pages and we can't
re-override that, so we just rm it during packaging.
Lastly, "cabal install" doesn't have a --destdir, and the --prefix has
to be the sandbox. This means the binaries will definitely store the
wrong path for data files. Thankfully, --enable-relocatable avoids
hardcoded paths entirely, so we just need to preserve relative paths.
At this point there's no reason to bother using "cabal copy", so we may
as well use "cabal install" and avoid the configure and build steps.
gitit only has one executable anyway!
|
|
Some other minor fixes:
- Improve error message about BUILDDIR being too small
- Create $pkgdir/usr/bin if absent (otherwise stack install fails)
- Add $pkgdir/usr/bin to PATH to avoid warnings from stack
|
|
TL;DR: Make sure your BUILDDIR has at least 8 GiB of space.
Switched from cabal to stack because cabal lacks isolation.
Cabal uses the global package database, so linking is affected by what
packages the user has installed at the time of build. One can't exactly
ignore the global database because the boot packages are needed. One
could ask for all the haskell-* system packages to be installed, but
that's a lot of tedious bookkeeping and we still have to deal with the
packages that aren't available through pacman, which would be stuck
inside the sandbox (unless one could somehow statically link those
libraries and dynamically link the system packages).
All in all, building using cabal sandboxes has become too complicated
due to the presence of dynamic-only system libraries in Arch. Stack
works out to be a bit simpler now, even though it involves reinstalling
ghc, incurring a dependency on stack, and having a large BUILDDIR.
Oh well.
|
|
See: https://github.com/jgm/gitit/blob/136b470c3d0ba691422c0979659de68f4edc175d/README.markdown#idle
|
|
|
|
|
|
|