| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Patch from Stephen Blackheath.
|
|
|
|
|
|
|
|
| |
This is sometimes needed when cross-compiling, as some packages may be
built in stage 0 but not stage 1.
In order to make everything work out, this also removes the requirement
that the build-dirs are in dependency order
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
We now use the 'host' to determine whether stage0 builds terminfo,
and 'target' to determine whether stage1 does.
We don't build it if the platform is either Windows or ios.
|
| |
|
|
|
|
|
| |
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
|
| |
|