| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This makes the build system a little simpler, and in particular
will make it easier to handle the changes needed for cross-compilation.
|
| |
|
|
|
|
| |
This means we don't define them multiple times
|
|
|
|
|
| |
The hsc2hs, alex and happy options variables are now also
non-way-specific, as the files are shared between all ways.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
From StephenBlackheath
|
| |
|
|
|
|
|
|
|
| |
This solves the problem of how to define MIN_VERSION_base for
the binary package.
Also fixed a couple of build system bugs along the way.
|
|
|
|
|
|
|
|
| |
This removes the '.PHONY' rule, so means that "make" in a built tree
won't repeat the check.
We also now check the .cabal files for the executables as well as the
libraries.
|
|
|
|
|
|
|
|
|
|
|
| |
If you were unlucky, the build could fail, e.g.:
utils\mkUserGuidePart\Main.hs:1:1:
Failed to load interface for `GHC.TopHandler'
There are files missing in the `base' package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
utils/mkUserGuidePart/ghc.mk:18: recipe for target `utils/mkUserGuidePart/dist/build/Main.o' failed
|
| |
|
|
|
|
| |
Since we can't run stage 2 on the host.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have two cases:
1. building a cross-compiler
2. compiling GHC to run on a foreign platform
These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.
Unfortunately, (2) didn't work, and the build system code needed some
tidying up.
Change to the way the build is set up:
Before
------
To build a cross-compiler:
./configure --target=<..>
To compile a foreign GHC:
./configure --host=<..> --target=<..>
Now
---
To build a cross-compiler:
./configure --target=<..>
And set "Stage1Only=YES" in mk/build.mk
To compile a foreign GHC:
./configure --target=<..>
|
|
|
|
|
| |
make thought that it could make a .hi file for the C files in
libraries, which was causing problems when using dynamic-too.
|
|
|
|
|
| |
This means that we can use the standard MonadIO class, rather than
needing our own copy.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Based on patch from Peter Trommler:
From 293495d40f62e691520331a41c6d85d82e120169 Mon Sep 17 00:00:00 2001
From: Peter Trommler <ptrommler@acm.org>
Date: Sun, 21 Oct 2012 18:47:01 +0200
Subject: [PATCH] Add configure option to use system provided libffi This
fixes track # 5743 and #4496.
|
|
|
|
|
| |
nus in #ghc ran into a problem where the wrong filepath was being
stripped.
|
|
|
|
|
|
|
|
|
| |
DeriveConstants.hs works in a cross-compilation-friendly way. Rather
than running a C program that prints out the constants, we just compile
a C file which has the constants are encoded in symbol sizes. We then
parse the output of 'nm' to find out what the constants are.
Based on work by Gabor Greif <ggreif@gmail.com>.
|
|
|
|
|
|
| |
We now do the initial dependency generation for the vanilla way
regardless of what way flags and hisuf/osuf flags are given. This
makes it easier to generate the right dependency info in the end.
|
|
|
|
| |
Avoids problems for people with old files in their tree
|
| |
|
|
|
|
| |
We were calling ranlib on the wrong path
|
| |
|
|
|
|
|
| |
This makes life easier, as ghc.mk has access to HADDOCK_DOCS
and DYNAMIC_BY_DEFAULT, so knows the right way to build it.
|
| |
|
| |
|
| |
|
|
|
|
| |
We shouldn't be generating files in the source directories
|
|
|
|
| |
When we have a dynamic ghc, we need to load the dynamic object files
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required various build system changes to get the build to go
through.
In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
to find their libraries. In the future, we might change the inplace tree
to be the same shape as an installed tree instead. However, this would
mean changing the way we do installation, as currently we use cabal's
installation methods to install the libraries, but that only works if
the libraries are under libraries/foo/dist-install/build/..., rather
than in inplace/lib/...
|
|
|
|
|
|
|
| |
Some binaries are installed in lib/, so if we wanted them to have a
shell wrapper then under the old scheme both the binary and the wrapper
would be installed under lib/. Now the binary is put under lib/bin/,
leaving lib/ for the wrapper.
|
|
|
|
| |
It's no longer needed in order to build the compiler itself.
|
|
|
|
| |
haskeline no longer depends on it
|
|
|
|
|
| |
Also added a comment explaining that addPackages need to be in
dependency order.
|
| |
|
|
|
|
|
| |
We also don't build DLLs for the dph-lifted-* packages as they depend
on ghc.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change reduces the (default) verbosity of the build system.
This makes it easier to spot warnings in the output and, also, it
makes it easier to estimate how far along are we in the build process
by just glancing at the output.
To get the traditional fully verbose output, set V=1, like this:
make V=1
|
| |
| |
| |
| | |
The bindist install directory was wrong.
|
| |
| |
| |
| | |
This means we no longer need mtl in a GHC tree.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Rename package database flags in both GHC and ghc-pkg so that they are
consistent with Cabal nomenclature.
Add a version check to the build system so that the correct set of
package db flags are used when the bootstrapping GHC has version < 7.5.
|
| | |
|