#define fork vfork
and then apparently call fork (in cbits/runProcess.c, IIRC) is
even worse.
This patch appears to `fix' (or hide?) the ENODEV errors spotted
by landry@ during bulk builds.
A complete GHC update will follow soon, so there's no reason for a bump.
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.
hs-glib (and probably other stuff that uses the Cabal library).
Bump both -main and -doc (yes, really, -doc, too).
I hereby nominate myself for the HSMAUS (Homer Simpson Memorial
Award of Unlimited Stupidity).
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
libc. While here, switch to new REVISION/WANTLIB scheme.
Problem noticed by ajacoutot@
ok espie@ sthen@
Please note that any Haskell library depending on ghc-6.12.3
(cabal-wise) needs to be rebuilt. This affects devel/haddock
and devel/hs-QuickCheck, which will be bumped in a minute, but
if you've some libraries not contained in the ports tree, be
sure to double-check with ghc-pkg check.
I fetched my distfile from the old place, before switching
MASTER_SITES to the new one (darcs.haskell.org). Same content,
but different size and checksums (because the files have been
created on different dates).
- 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.
Since the new bootstrapper has a new name (ghc-6.12.2.20100530),
the ABI of some libraries included in GHC will change, possibly
breaking all other libraries, so expect some additional bumps soon.
Yes, this *is* ridiculous. If you want to live in peace, don't use
GHC.
paraemters to ghc-pkg. Remove the (now obsolete) patch for Register.hs.
Ports that build ghc libraries should now use the following
@exec/@unexec magic (('ve already diffs for all the hs-* ports in
my tree):
lib/${DISTNAME}/register.sh
@exec /usr/bin/env HOME=/nonexistent %D/lib/${DISTNAME}/register.sh -v0
@unexec /usr/bin/env HOME=/nonexistent %D/lib/${DISTNAME}/unregister.sh -v0 --force
lib/${DISTNAME}/unregister.sh
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.
the APIs of GHCs libraries depend on the version of the bootstrapping
compiler (and probably on the output of pom(6) and the amount of
active vulcanos in iceland).
See http://hackage.haskell.org/trac/ghc/ticket/4012#comment:3 for
details.
THIS ALSO MEANS THAT IF YOUR BUILD FAILS, YOU WILL HAVE TO MAKE
CLEAN AND START FROM SCRATCH! NEVER EVER TRY TO RESTART THE BUILD
OR THE LIBRARY ABIS WILL CHANGE! (Sorry for yelling)
Bump PKGNAME-main, since people may already have built ghc with
native_bootstrap.
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}.
If you have to work on ghc-HEAD but can't get the ghc-HEAD souces, there's
no point to work on it at all.
If you complain about missing portability, and all those Haskell guys agree,
but at the same time delay bootstrapping to the next release whenever a
release happens, there's no expectation for getting bootstrapping back at
all.
