| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Spotted by Marco Túlio Gontijo e Silva
|
| | |
|
| |
|
|
| |
them off
|
| |
|
|
| |
MERGE TO STABLE
|
| |
|
|
| |
ignored
|
| | |
|
| |
|
|
|
|
| |
Fixed hsc2hs handling and added hpc binary. Explicitly generate Cabal docs.
Note that the Haddock documentation is currently not in the right place,
this needs more investigation, but at least we can build a valid RPM now.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ATTENTION: Packagers should read the following stuff carefully!
GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
one hand this is quite handy, avoiding lots of tiny native packages, but OTOH
this leads to a few problems:
* The tools are not always identical in functionality.
* The tools fight for a global generic name like "/usr/bin/runhaskell".
These problems are not new and not unique to Haskell implementations, so for
*nix-based system there is a tool called update-alternatives which handles
those cases. The idea is as follows:
* Each program/man page/etc. installs itself with a very specific name
like /usr/bin/hsc2hs-ghc or /usr/share/man/man1/lua5.1.1.gz, so nothing
clashes.
* The (un-)installation scripts call update-alternatives to notify the
system about new alternatives for a generic tool/manpage/etc.
* Alternatives can be grouped together ("link groups"), so e.g. switching
from Sun's Java to Kaffe switches compiler, JRE, manpages etc. together.
Alas, this doesn't work well with the Haskell implementations yet,
because they come with different sets of tools (in addition to runFOO):
GHC: hsc2hs
Hugs: hsc2hs, cpphs
nhc: cpphs
Either these tools should be disentangled fromt the Haskell
implementations or all implementations should offer the same set.
Opinions and recommendations on this topic are highly welcome.
* This mechanism can be used to easily switch between several versions of
the same implementation, too, but we are not yet fully prepared for that.
As a first step, GHC now installs hsc2hs as 'hsc2hs-ghc' and does *not*
install runhaskell directly anymore, only runghc. hsc2hs and runhaskell are
created via update-alternatives now. What is currently missing is a mechanism
for platforms like Windows and probably Mac OS X.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, one can define the degree of build parallelism via a 'jobs'
rpm variable. A comfortable way to use this is having a ~/.rpmmacros file with
a line like:
%jobs 2
Alternatively, one could use a '--define "jobs 2"' command line flag for
rpmbuild. On a Core 2 Duo using 2 jobs brings down the time for a full build
including extralibs from 36m to 27m. If 'jobs' is not defined, a normal
sequential build is done, following the usual conventions on e.g. openSUSE.
|
| | |
|
| | |
|
| |
|
|
| |
haddock-html)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
