| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# -----------------------------------------------------------------------------
#
# (c) 2009 The University of Glasgow
#
# This file is part of the GHC build system.
#
# To understand how the build system works and how to modify it, see
# http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture
# http://hackage.haskell.org/trac/ghc/wiki/Building/Modifying
#
# -----------------------------------------------------------------------------
|
| |
|
|
|
|
|
| |
One side-effect of this is that we need to build the install-utils with
stage2 rather than stage1 as we need the ghc package.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Compat.Unicode is not utils/Unicode in the compiler.
We build the hpc package with the stage1 compiler.
Nothing else in the compat package was still used.
|
|
|
|
| |
We now get them from the bootstrapping package.conf instead
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- GHC installs a range of compiled Haskell programs in addition to the actual
compiler. To ensure that they all run on the platform targeted by the build
(which may have different libraries installed than the build host), we need
to make sure that all compiled Haskell code going into an install is build
with the stage 1 compiler, not the bootstrap compiler. Getting this right
is especially important on the Mac to enable builds that work on Mac OS X
versions that are older than the one performing the build.
- For all installed utils implemented in Haskell (i.e., ghc-pkg, hasktags,
hsc2hs, runghc, hpc, and pwd) we compile two versions, an inplace version
and a version for installation. The former is build by the bootstrap
compiler during the stage 1 build and the latter is build by the stage 1
compiler during the stage 2 build.
- This is really very much as the setup for ghc itself, only that we don't use
separate stage1/ and stage2/ build directories. Instead, we clean before
each build. CAVEAT: This only works properly if invoked from the
toplevel Makefile.
- Instead of UseStage1=YES (as used by the previous binary-dist-specific
recompilation), we now use the same $(stage) variables as used for the
compiler proper - to increase uniformity and to avoid extra conditionals for
the install target.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- #1839 asks for a ghc-pkg dump feature, #1463 for the ability
to query the same fields in several packages at once.
- this patch enables substring matching for packages in 'list',
'describe', and 'field', and for modules in find-module. it
also allows for comma-separated multiple fields in 'field'.
substring matching can optionally ignore cases to avoid the
rather unpredictable capitalisation of packages.
- the patch is not quite as full-featured as the one attached
to #1839, but avoids the additional dependency on regexps.
open ended substrings are indicated by '*' (only the three
forms prefix*, *suffix, *infix* are supported)
- on windows, the use of '*' for package/module name globbing
leads to conflicts with filename globbing: by default, windows
programs are self-globbing, and bash adds another level of
globbing on top of that. it seems impossible to escape '*'
from both levels of globbing, so we disable default globbing
for ghc-pkg and ghc-pkg-inplace. users of bash will still
have filename globbing available, users of cmd won't.
- if it is considered necessary to reenable filename globbing
for cmd users, it should be done selectively, only for
filename parameters. to this end, the patch includes a
glob.hs program which simply echoes its parameters after
filename globbing. see the commented out glob command in
Main.hs for usage or testing.
- this covers both tickets, and permits for the most common
query patterns (finding all packages contributing to the
System. hierarchy, finding all regex or string packages,
listing all package maintainers or haddock directories,
..), which not only i have wanted to have for a long time.
examples (the quotes are needed to escape shell-based
filename globbing and should be omitted in cmd.exe):
ghc-pkg list '*regex*' --ignore-case
ghc-pkg list '*string*' --ignore-case
ghc-pkg list '*gl*' --ignore-case
ghc-pkg find-module 'Data.*'
ghc-pkg find-module '*Monad*'
ghc-pkg field '*' name,maintainer
ghc-pkg field '*' haddock-html
ghc-pkg describe '*'
|
| |
|
|
|
|
|
|
| |
directories
MERGE TO STABLE
|
|
|
|
|
|
|
| |
They are now the same as hardtop/FPTOOLS_TOP_ABS, so use those instead.
Also removed some substitutions of / for \, as we now use a Haskell
program to find the top path, and it only makes paths with /s in.
|
| |
|
| |
|
|
|
|
| |
$(UseStage1) modifies $(HC) rather than $(GHC)
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Fixes various problems with getting the scripts right on Windows.
Binaries are universally executable by /bin/sh, cmd.exe and rawSystem,
so this allows us to remove some platform-specific hacks.
|
|
|
|
|
| |
Bindists should now work again, when doing "make install" at least.
"make in-place" is probably still broken.
|
|
|
|
|
|
| |
Key changes:
* Always build as if BIN_DIST is 1. BIN_DIST is thus removed.
* Libraries are configured with prefix set to $$topdir rather than $(prefix)
|
| |
|
|
|
|
| |
See bug #1295
|
|
|
|
|
|
|
|
|
|
|
| |
The bat-script generation was using the wrong paths, in
ghc-inplace
ghc-pkg
hsc2hs
plus there was a double-backslah in the latter two which was wrong.
This patch fixes both. See "MSys Note 3" in compiler/Makefile
|
| |
|
| |
|
|
|
|
| |
This fixes building the compiler with -prof in $(GhcStage1HcOpts)
|
| |
|
|
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.
|