Also, use a new(er) bootstrapper; note that we have to use 7.8.3
for this, because if the built ghc and the bootstrapper have identical
versions, things will fail badly. May be it's not the ghc but the
cabal version which is problematic, but at the moment, I really
don'y call about *this* problem.
Still marked as broken. I hope to send promised diffs and new ports
for discussion tomorrow and then enable ghc and haskell-platform
on monday.
stop other people wasting time on updates which should not be done.
ian@ ran into this (while working on devel/hs-aeson and
textproc/hs-attoparsec), and even I didn't notice before trying to
build all Haskell ports (including meta/haskell-platform) with his
diffs.
So let's switch to compiling Setup scripts once more, to give at least
a few more hs packages to be built on i386, until I figure out a fix
for rts/Linker.c.
Unfortunately, the current breakage also affects template haskell,
which still leads to a lot of unbuildable ports, for example
devel/hs-vector.
instead of using runghc (the interpreter).
This is a *workaround* for the following two symptoms:
- Setup.hs: waitForProcess: resource exhausted (Resource temporarily
unavailable)
- Setup.hs: fd:15: hGetContents: illegal operation (Inappropriate
ioctl for device)
Note that this is not a *fix*. I'm sure there's some misbehaving
signal handler, either in runghc/ghci or in the ghc runtime library.
(No, it's *not* rts/posix/Signals.c:generic_handler(); I patched
it to preserve errno, but it didn't help)
Until I find the bug, it's better to let bulk builds pass without
(or with less) errors.
ok (with the workaround) espie@
into a common subdirectory `ghc', and also move the ghc distfiles
there (from ghc-${MODGHC_VER}).
This will avoid potential conflicts of hs-* ports distfiles coming
from hackage.haskell.org with distfiles used by other ports.
Based on an idea from dcoppa@ for databases/hs-redis.
ok dcoppa@
If you want to save some bandwdith and disk space, see my mail to
ports@, which contains a shell script that can move distfiles around
under your DISTDIR.
libraries not coming together with ghc. This allows for looking up
a library's PKGPATH by running
ghc-pkg field $pkgname pkgpath
where $pkgname is the GHC library name without the `hs-' prefix,
for example `ghc-paths'.
looks good to jasper@
cabal and without nort), to avoid collisions with other (non-Haskell)
ports;
- Documentation is installed as ${PREFIX}/share/doc/hs-$foo instead of
${PREFIX}/share/doc/$foo.
- The library itself (and its interface files) is installed as
${PREFIX}/lib/ghc/$foo instead of ${PREFIX}/lib/$foo.
- Additional files will be installed in ${PREFIX}/share/hs-$foo instead
of ${PREFIX}/share/foo.
from kili@
depending port's plists will be adjusted in a few
- Use integer-gmp again.
- Cleanout the extracted bootstrap directory right after installing it
to save some disk space.
- Use ${MAKE_ENV} instead ${MODGHC_SETUP_CONF_ENV} in ghc.port.mk (in
do-configure, use both).
- Don't compile Setup.l?hs, just use the interpreter (runghc) in
ghc.port.mk. This speeds up the build of most ports depending on
ghc and using a cabal-style build.
Necessary bumps and WANTLIB changes in ports using ghc will follow
later this evening.
just setting MODGHC_SETUP_CONF_ARGS (which is now empty by default).
Add dblatex-created documentation.
While here, use our INSTALL* macros where possible to get correct
permissions (noticed by dcoppa@). This does *not* fix the permissions
of libraries and interface files installed by Cabal-based tools,
because the permissions are hard-coded in Cabal, and I'm not going
to touch and fix Cabal ever, because IMHO it's completely broken
by design. (If you want to read some of this madness, have a look
at libraries/Cabal/Distribution/Compat/CopyFile.hs or even
libraries/Cabal/Distribution/Simple/Install.hs)
Expect some breakage of depending ports (at least of devel/darcs) and
some necessary WANTLIB changes, which will be fixed soonish.
Many thanks to Darrin Chandler and dcoppa@ for testing, reporting about
broken stuff, missing dependencies here and in ports depending on ghc.
Notes and rants:
- Bootstrapping is done using precompiled binaries, since .hc
bootstrapping still doesn't work. I really hate this.
THIS MEANS THAT GHC IS NOW AND WILL STAY LEGACY-ONLY (i386 and amd64)
At least until someone fixes it. I tried for more than two year
(well, only in my spare time and during my vacations) and failed.
- libgmp is currently disabled, because I didn't yet hack the GHC build
system to use the system libgmp instead of the patched one included
in GHC.
- The haddock ncluded in the ghc distfile is replaced by the version
of haddock found in devel/haddock. Haddock itself is @commented
in the ghc PLIST. Unfortunately, this needs an ugly hack that
introduces an otherwise useless pseudo flavor `no_deps' in
devel/haddock.
- CLDouble has been removed from GHC some time ago, because it was
an alias for double (AFAIK there's now support for long double
in GHC). As this isn't a really big problem, it currently breaks
c2hs, which I'll mark broken temporarily before committing the
ghc update.
- The external codeset defaults to latin1 (suggested by Simon Marlow)
and can be overridden by setting the HS_ENCODING to any codeset
supported by libiconv.
- ghc.port.mk still needs some love, especially for letting a port add
additional parameters to certain invocations of ${MODGHC_SETUP_PROG}.
