to configure env so that it doesn't try to run tests that goes into an infinite
loop puking 'longjmp botch'. If anyone feels brave enough to debug that,
start in m4/sigaltstack*. That should allow quite a good branch of the
portstree to build again..
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}.
Glib now enforces threads requirement. As a result, this commit will
break p5-Glib2 (as our perl is not threaded).
Decision was taken after a chat with naddy@ and jasper@ as patching our
current glib2 like hell to cope with newer packages requirements is
clearly not a good solution.
naddy is ok with this move.
The rules module allows site administrators to define conditionally
executed actions based on occurring events (known as reactive or ECA
rules).
ok landry@
