summaryrefslogtreecommitdiff
path: root/rules/shell-wrapper.mk
Commit message (Collapse)AuthorAgeFilesLines
* Don't use $SHELL in wrapper scriptsJoachim Breitner2017-10-261-3/+3
| | | | | Do not use $SHELL as $SHELL is the user's preferred interactive shell. We do not want this to leak into the wrapper scripts.
* Rework CC/CC_STAGE0 handling in `configure.ac`Herbert Valerio Riedel2016-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...` scheme use the `CC=...` style scheme. The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to stage{1,2,3}, while having a separate _STAGE0 set of env-vars denote the bootstrap-toolchain flags/programs. This should be simpler, less confusing, and somewhat more in line with Autoconf's idioms (allowing us to reuse more of Autoconf rather than (re)inventing our own confusing non-standard m4 macros to do stuff that Autoconf could almost do already for us) Morever, expose CC_STAGE0 as a so-called "precious" variable. So now we can better control which bootstrapping gcc is used (by default the one used by the stage0 ghc, unless CC_STAGE0 is overriden) ``` Some influential environment variables: CC_STAGE0 C compiler command (bootstrap) CC C compiler command CFLAGS C compiler flags ... Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. ``` Test Plan: I've tested that cross-compiling with `--target=powerpc-linux-gnu` still works, and tried a few variants of settting `CC=` and `CC_STAGE0=`; `./validate` passed as well Reviewers: erikd, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2078
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Build system: simplify install.mk.inThomas Miedema2015-08-211-1/+1
| | | | | | | | | | This will allow fixing #1851 more easily ("make install-strip" should work). This reverts 57e2a81c589103b50da80a9e378b1a11285bd521: "On Cygwin, use a Cygwin-style path for /bin/install's destination" Update submodule haddock and hsc2hs.
* Build system: also clean the inplace wrapperThomas Miedema2015-05-301-0/+2
| | | | | | | | | | | | | | | | | Running `make clean` inside `utils/runghc` now does: "rm" -rf utils/runghc/dist-install "rm" -rf inplace/bin/runghc "rm" -rf inplace/lib/bin/runghc Instead of just: "rm" -rf utils/runghc/dist-install "rm" -rf inplace/lib/bin/runghc I think this was just an oversight. [skip ci] Differential Revision: https://phabricator.haskell.org/D919
* Build system: don't use supposedly local variable inside macroThomas Miedema2015-05-301-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is no support for local variables inside `make` macros (defined using the `define` keyword), see [wiki:Building/Architecture/Idiom/Macros]. In this case `make show VALUE=INPLACE_WRAPPER` would print some bogus value ("inplace/bin/mkUserGuidePart" actually, from the last BUILD_DIRS entry in ghc.mk that calls shell-wrapper), and using that variable somewhere might be a bug. Test Plan: I checked the rules directory with the following crude regexp, and this seems the be the only real offender. grep -P '^[^ $#\t][^$]*[^+]=' rules/* What it is supposed to do (from right to left): * look for variable assignments * but not updates (+=) * where the variable name doesn't contain any dollar signs * and the line doesn't start with whitespace or a comment [skip ci] Differential Revision: https://phabricator.haskell.org/D918
* Build system: whitespace and comments onlyThomas Miedema2015-05-301-3/+6
| | | | [skip ci]
* runghc: be explicit about ghc version (#9054)Thomas Miedema2015-02-181-3/+5
| | | | | | | | | | | | | | Summary: runghc-7.x should always call ghc-7.x Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D664 GHC Trac Issues: #9054
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* Comment fixGabor Greif2013-08-311-1/+1
|
* Don't try to build bindist wrappers on WindowsIan Lynagh2013-05-151-0/+2
|
* By default, use the dynamic way for programs in the GHC treeIan Lynagh2013-03-151-2/+2
| | | | | In particular, this means that GHCi will use DLLs, rather than loading object files itself.
* Automatically add the $(exeext) to program namesIan Lynagh2013-03-031-2/+2
| | | | | | | 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).
* Make it possible to build with only way dynIan Lynagh2012-10-241-15/+30
|
* extend LD_LIBRARY_PATH instead of replacing itGabor Greif2012-10-241-3/+3
|
* Get dynamic-by-default mostly working on OS XIan Lynagh2012-10-141-0/+4
|
* Build the dynamic way by default on Linux/amd64Ian Lynagh2012-10-031-37/+24
| | | | | | | | | | | | | 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/...
* Refactor the shell-wrapper-creation logicIan Lynagh2012-10-011-6/+33
|
* Put libexec binaries in lib/bin/ rather than just lib/Ian Lynagh2012-10-011-1/+1
| | | | | | | 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.
* Tweak the build system handling of shell wrappersIan Lynagh2012-09-271-15/+4
| | | | | | | Rather than having a separate foo_INSTALL_SHELL_WRAPPER variable, we just use foo_INSTALL && foo_SHELL_WRAPPER
* Improve support for cross-compilationSimon Marlow2012-01-301-1/+1
| | | | Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>
* Improve the way we call "rm" in the build system; fixes trac #4916Ian Lynagh2011-11-191-2/+2
| | | | | | | | | | We avoid calling "rm -rf" with no file arguments; this fixes cleaning on Solaris, where that fails. We also check for suspicious arguments: anything containing "..", starting "/", or containing a "*" (you need to call $(wildcard ...) yourself now if you really want globbing). This should make things a little safer.
* We no longer need to pass pgmc etc in the ghc.wrapper scriptIan Lynagh2011-04-291-1/+0
| | | | They can now be set in the settings file instead
* Add build system profiling to build systemIan Lynagh2011-01-231-0/+2
|
* On Cygwin, use a Cygwin-style path for /bin/install's destinationIan Lynagh2011-01-061-1/+1
| | | | | | | | | | | | | | | | | cygwin's /bin/install doesn't set file modes correctly if the destination path is a C: style path: $ /bin/install -c -m 644 foo /cygdrive/c/cygwin/home/ian/foo2 $ /bin/install -c -m 644 foo c:/cygwin/home/ian/foo3 $ ls -l foo* -rw-r--r-- 1 ian None 0 2011-01-06 18:28 foo -rw-r--r-- 1 ian None 0 2011-01-06 18:29 foo2 -rwxrwxrwx 1 ian None 0 2011-01-06 18:29 foo3 This causes problems for bindisttest/checkBinaries.sh which then thinks that e.g. the userguide HTML files are binaries. We therefore use a /cygdrive path if we are on cygwin
* add a simple trace facility to the build systemSimon Marlow2010-09-211-0/+1
| | | | | | | | | saying make TRACE=1 prints most of the macro calls and their arguments. It's easy to trace new macros; see rules/trace.mk.
* Inplace programs depend on their shell wrappersIan Lynagh2010-04-271-1/+1
|
* Pass the location of gcc in the ghc wrapper script; partially fixes #3863Ian Lynagh2010-03-241-0/+2
| | | | This means we don't rely on baking a path to gcc into the executable
* Tweak how shell wrappers are builtIan Lynagh2009-11-071-4/+5
|
* ghc-stage2 is now renamed to ghc when it is installedIan Lynagh2009-11-071-1/+5
| | | | This means that we get the right program name in error messages etc.
* Tweak the shell wrapper scriptsIan Lynagh2009-11-071-1/+3
| | | | | We now separate the executable path from the executable name. This will allow us to change one but not the other easily.
* Make installation on *nix work for paths with spaces in their nameIan Lynagh2009-11-051-13/+13
| | | | | | This means we can remove some conditional stuff from the Makefiles, and means the testsuite doesn't have to work out whether or not it's on Windows.
* Make our install variables etc compliant with GNU standards; fixes #1924Ian Lynagh2009-08-141-8/+10
|
* Fix permissions when installingIan Lynagh2009-08-021-1/+2
|
* Quote commands that we run, so they work if there are space in their pathsIan Lynagh2009-05-301-7/+7
| | | | | I've also added some missing $s to some makefiles. These aren't technically necessary, but it's nice to be consistent.
* Add a header to all build system files:Simon Marlow2009-04-281-0/+12
| | | | | | | | | | | | | | # ----------------------------------------------------------------------------- # # (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 # # -----------------------------------------------------------------------------
* GHC new build system megapatchIan Lynagh2009-04-261-0/+63
View Lorry Controller Status