| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
We now define _PROGNAME, and _PROG is automatically defined with
$(exeext). This will shortly automatically use the right exeext
depending on what stage it is being compiled with (exeext may be
different for different stages when cross-compiling).
|
|
|
|
| |
and use them for split
|
|
|
|
|
| |
It doesn't seem to do anything that _INSTALL and _INSTALL_INPLACE
can't do.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Based on patch from Stephen Blackheath.
|
| |
|
|
|
|
|
| |
This makes the build system a little simpler, and in particular
will make it easier to handle the changes needed for cross-compilation.
|
|
|
|
|
| |
Using { } with sed on OS X requires using newlines rather than
semicolons. I've rewritten the sed so that no { } are necessary.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a file is created by a %.hi rule, and the actual filename isn't
mentioned in the makefiles, then make will treat it as an 'intermediate
file' and delete it when it is finished.
We'd been lucky so far that .hi files weren't actually being built due
to our rules (but rather, as side-effects of the .o rules). However,
when using -dynamic-too to build, we had a rule
$1/$2/build/%.$$(dyn_osuf): $1/$2/build/%.$$(v_hisuf)
which meant that building a .dyn_o could cause the rule for the
corresponding .hi to be used, and the .hi may then be deleted later on.
This was exacerbated by a bug in GNU make 3.81 which caused make to
enter an infinite loop if running in parallel mode:
http://lists.gnu.org/archive/html/bug-make/2013-02/msg00020.html
Adding
.SECONDARY:
would stop make from deleting the intermediate files. However, this
caused make to take a pathologically long time (it appeared to be
live-locked for 2 hours before I killed it) with our build system.
This patch instead creates lines like
$(eval $(call hi-rule,libraries/base/dist-install/build/Unsafe/Coerce.dyn_hi libraries/base/dist-install/build/Unsafe/Coerce.hi : %hi: %o libraries/base/Unsafe/Coerce.hs))
in the .depend files, which results in a rule like
libraries/base/dist-install/build/Unsafe/Coerce.dyn_hi libraries/base/dist-install/build/Unsafe/Coerce.hi : %hi: %o libraries/base/Unsafe/Coerce.hs ;
which, as the files are now all named in the makefiles, means they are
no longer intermediate files so do not get deleted.
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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=<..>
|
|
|
|
|
|
| |
Otherwise the configure script for e.g. base doesn't know that we're
cross-compiling, and fails trying to run an executable compiled by the
C cross-compiler.
|
| |
|
|
|
|
| |
hs-suffix-rules now calls hs-suffix-rules-srcdir, saving some duplication
|
|
|
|
|
|
|
| |
Whether we check that .hi files have actually been created is now
controlled by $(ExtraMakefileSanityChecks) (defaults to NO).
Also updated comments about the .hi rule.
|
|
|
|
|
|
| |
We were adding "maintainer-clean : distclean" every time we call
build-package. All of these are redundant, as the same dependency
appears in the root ghc.mk.
|
|
|
|
|
| |
We don't want the overhead of spawning a shell on Windows, but on other
platforms it's a useful sanity check.
|
|
|
|
|
| |
make thought that it could make a .hi file for the C files in
libraries, which was causing problems when using dynamic-too.
|
|
|
|
|
|
| |
I don't think we need these, and they haven't been doing anything
useful for dynamic-by-default builds anyway as they hardcode the 'v'
way.
|
|
|
|
| |
Based on a patch from markwright in #3072.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is a kludge. A proper fix probably involves improving the "ghc -M"
flags to handle this sort of case better.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
There are better dependencies for this in the DPH package, where all
the TH is.
|
| |
|
|
|
|
|
|
| |
Even though e.g. inplace/bin/hpc doesn't normally need a shell wrapper,
it does when we are using dynlibs, as we need to set the
LD_LIBRARY_PATH so that it can find its libraries.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
When building things to run in the build tree, we want the install name
to be the location in the build tree.
Bindists may be installed somewhere other than the configured install
location, so we weren't even necessarily setting it to the right value.
|
|
|
|
| |
It doesn't really belong in package-data.mk
|
| |
|