summaryrefslogtreecommitdiff
path: root/rules/build-prog.mk
Commit message (Collapse)AuthorAgeFilesLines
* Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.hJohn Ericson2019-10-041-1/+1
| | | | | | | | | | | | | | | | | | The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
* Lowercase windows importsMoritz Angermann2019-05-271-2/+2
| | | | | | | | | | While windows and macOS are currently on case-insensitive file systems, this poses no issue on those. When cross compiling from linux with a case sensitive file system and mingw providing only lowercase headers, this in fact produces an issue. As such we just lowercase the import headers, which should still work fine on a case insensitive file system and also enable mingw's headers to be usable porperly.
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-1/+1
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* rules/build-prog: Ensure programs depend upon their transitive depsBen Gamari2016-05-171-1/+3
| | | | | | | | | | Previously programs only depended upon the direct dependencies; while I would have thought that this would be sufficient, somehow we were getting to the link step of building `ghc-pkg` before `ghc-boot-th` was built (despite the fact that `ghc-boot` has a direct dependency on `ghc-boot-th`). See #12078.
* Enable stack traces with ghci -fexternal-interpreter -profSimon Marlow2016-01-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main goal here is enable stack traces in GHCi. After this change, if you start GHCi like this: ghci -fexternal-interpreter -prof (which requires packages to be built for profiling, but not GHC itself) then the interpreter manages cost-centre stacks during execution and can produce a stack trace on request. Call locations are available for all interpreted code, and any compiled code that was built with the `-fprof-auto` familiy of flags. There are a couple of ways to get a stack trace: * `error`/`undefined` automatically get one attached * `Debug.Trace.traceStack` can be used anywhere, and prints the current stack Because the interpreter is running in a separate process, only the interpreted code is running in profiled mode and the compiler itself isn't slowed down by profiling. The GHCi debugger still doesn't work with -fexternal-interpreter, although this patch gets it a step closer. Most of the functionality of breakpoints is implemented, but the runtime value introspection is still not supported. Along the way I also did some refactoring and added type arguments to the various remote pointer types in `GHCi.RemotePtr`, so there's better type safety and documentation in the bridge code between GHC and ghc-iserv. Test Plan: validate Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1747 GHC Trac Issues: #11047, #11100
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Build system: don't add ALL_HC_OPTS when linking"Ben Gamari2015-10-291-1/+1
| | | | | | | This reverts commit 9fc2d777f53110040f48ab27643a16888fa377f5. This appears to cause interface file issues during rebuilds. Punting back to @thomie for further investigation.
* Build system: don't add ALL_HC_OPTS when linkingThomas Miedema2015-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current scheme in rules/distdir-way-opts.mk is something like this: GHC_LD_OPTS = MOST_HC_OPTS + ALL_LD_OPTS MOST_DIR_HC_OPTS = MOST_HC_OPTS + -odir,-hidir,-stubdir ALL_HC_OPTS = MOST_DIR_HC_OPTS + -hisuf,-osuf,-hcsuf,-split-objs,-dynamic-too Notice that both ALL_HC_OPTS and GHC_LD_OPTS include MOST_HC_OPTS, and currently both got added when linking. Adding MOST_HC_OPTS twice results in overly long and hard to decipher command lines (and build logs). This commit fixes that. Afaik, -odir,-hidir,-stubdir,-hisuf,-osuf,-hcsuf,-spit-objs,-dynamic-too are all not needed when linking, so this change should be safe to make. GHC_LD_OPTS is for linking, ALL_HC_OPTS is for compiling. ALL_HC_OPTS was added to the linking commands in 37a6a52facd1c3999ce4472c50b0030568be1e04, to make sure -no-user-package-conf would be in the options list. It still is after this change. Reviewers: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1379
* Build system: comments only [skip ci]Thomas Miedema2015-10-271-1/+1
|
* Build system: fix `make -j1` (#10973)Thomas Miedema2015-10-171-6/+1
| | | | | | | | | | | | | | | | | | | | There are multiple hacks all over the build system to account for the fact that the ghc package uses different build subdirectories (stage1/stage2) than the other packages (dist/dist-install). One such hack filtered on 'ghc%', with the intention of filtering the ghc package only. After renaming bin-package-db to ghc-boot (d2f9972a35ce05ceb8a78893e433ef1df06f73ef, Phab:D1313, #10796), ghc-boot also got caught in the hack, which broke the build when running without parallelism. This patch replaces the before mentioned hack by a different one, such that filtering on 'ghc%' is no longer necessary. See Note [inconsistent distdirs]. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1333
* Rename PACKAGE_KEY and LIB_NAME in build system.Edward Z. Yang2015-10-141-2/+2
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Build system: implement `make install-strip` (#1851)Thomas Miedema2015-09-041-1/+1
| | | | | | Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1209
* Make $1 in $1_$2_$3_FOO actually be directory.Edward Z. Yang2015-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we used $1_$2_PACKAGE_KEY to parametrize $1. But the documentation says that $1 should be the directory... and we're now putting the libraries in $1_$2_LIB_NAME. So use /that/. This is just alpha-renaming, so as long as we're consistent, there's no material difference.) I also fixed a bug of a package ID calculation which I missed first time around, which was tickled by this change. BTW, this means DEP_KEYS and TRANSITIVE_DEP_KEYS are unused, so remove them from ghc-cabal. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1010
* Fix #10551 by using LIB_NAMES.Edward Z. Yang2015-06-221-1/+1
| | | | | | | | | | | | | | | | | | Summary: (NB: this code is dead at the moment since Windows is not built dynamically.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: none Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1001 GHC Trac Issues: #10551
* Build: remove more unnecessary CLEANING/=YES checksThomas Miedema2015-06-041-4/+0
| | | | | | | | | | | | | All these checks that CLEANING/=YES are no longer needed, because nowadays $1_$2_PROGNAME is always set explicitly, and $1_$2_PROG isn't. They were once introduce to allow `make clean` before `./configure`. I checked, and it still works. Remove the checks to make the build system a tiny bit shorter, and to no longer wonder why they are there. Differential Revision: https://phabricator.haskell.org/D941
* Build: remove unnecessary CLEANING/=YES checkThomas Miedema2015-06-041-3/+0
| | | | | | | | | | | | | | | | | | | The comment "INPLACE_BIN might be empty if we're distcleaning" is no longer true, and the check that CLEANING isn't YES isn't necessary. It was introduced in cd12c32de77ac18a69ed1733a558095567ec5ba8, to "make repeated 'make distclean' not fail", and and later revised in 39253008705e3ca590afdfa1b87bfbb5a16da7e7. It was needed because INPLACE_BIN was defined in config.mk. Commit 6793a033e1ce41f77316675e8f7aa83196a9b211 however, two days later, introduced a better solution to this problem: "Move the fixed paths out of config.mk, so cleaning works without configuring" So here we remove the original comment and check. One less thing to worry about when trying to understand the build system. Differential Revision: https://phabricator.haskell.org/D940
* Build system: make clean in utils/ghc-pkg should not delete inplace/lib/binThomas Miedema2015-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure $1_$2_PROG always gets assigned a value, even when cleaning. The problem with not setting the variable becomes apparent when looking at the following two lines of code: ``` $1_$2_INPLACE = $$(INPLACE_LIB)/bin/$$($1_$2_PROG) $(call clean-target,$1,$2_inplace,$$($1_$2_INPLACE)) ``` So running `make clean` in for example `utils/ghc-pkg` deletes `inplace/lib/bin/` instead of `inplace/lib/bin/ghc-pkg`. The offending code was introduced in commit 2b85372ca18115bb1d6363256fcea6f54e415bed. There is one small implication. When cleaning before configure, the variable $1_$2_PROG will now be assigned a slightly wrong value, because exeext$3 isn't known yet. But I think that's ok, as no files have been build yet, so it will just try to delete a slighly different nonexistent file. [skip ci] Differential Revision: https://phabricator.haskell.org/D916
* Build system: whitespace and comments onlyThomas Miedema2015-05-301-3/+12
| | | | [skip ci]
* Build system: check $CLEANING instead of $MAKECMDGOALSThomas Miedema2015-05-301-3/+3
| | | | | | | To check if we're cleaning, always check the $CLEANING variable, instead of sometimes $CLEANING, sometimes $MAKECMDGOALS. [skip ci]
* runghc: be explicit about ghc version (#9054)Thomas Miedema2015-02-181-5/+1
| | | | | | | | | | | | | | 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
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* Use 'install' command for 'inplace/' install as we do in 'make install'Sergei Trofimovich2014-08-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On hardened gentoo ghc-stage2 does not work as-is, as it uses runtime code generation/loading, thus ghc0stage2 needs to be marked in a special way (via POSIX extened attributes). Before the patch we used 'cp -p' command, which does not preserve that marking. It leads to buid failure on hardened. Hardened's 'install' does preserve POSIX xattrs, thus patch uses it instead. 'inplace/' directory can be seen the same way as target for 'make install', thus using the same facilities to install files to 'inplace/' sounds more consistent. Reported-by: Jay Yang Gentoo-bug: https://bugs.gentoo.org/518734 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: tested ghc installation on vanilla and hardened distributions Reviewers: austin Reviewed By: austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D108
* Include EXTRA_LD_OPTS (amongst other things) when linking programsSimon Marlow2014-03-271-2/+2
| | | | | | | | | | One problem was that we weren't including $1_$2_DIST_LD_OPTS when linking a program, which looks to be accidental: it was being defined but not used anywhere. This meant that setting $1_$2_EXTRA_LD_OPTS, for example, had no effect. This commit straightens out the handling of LD_OPTS to be consistent with the way we handle CC_OPTS and HC_OPTS.
* Fix inplace dynamic linking on OS X (#8266)Christiaan Baaj2014-01-281-4/+0
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Fix make binary-dist on OS X (#8122)Austin Seipp2013-11-221-6/+7
| | | | | Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Correctly set relative rpath for OS X (#8266)Austin Seipp2013-10-251-1/+2
| | | | | | | | | This includes both executables (by correcly setting the rpath to the topDir) and libffi, and GHC itself, so that everything works with no build tree. Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* Fix the dynmaic library paths in the libs, as well as in the programsIan Lynagh2013-06-221-12/+2
| | | | Part of #7833
* On OS X, fix the path to the libffi dynlib; fixes #7833Ian Lynagh2013-06-221-0/+1
|
* Don't link base/rts/... into C wrapper programsIan Lynagh2013-05-161-2/+2
|
* Make dynamic GHC no Windows installable tooIan Lynagh2013-05-161-11/+32
| | | | | We need different paths in the wrapper, as teh installed tree is a different shape to the build tree.
* Define the right RTS config in the Windows dyn wrapper programsIan Lynagh2013-05-141-0/+17
| | | | | | This is particularly important as without it validate fails, as it tries to pass RTS options to haddock, and with the default RTS config those options aren't permitted.
* More work towards dynamic programs on WindowsIan Lynagh2013-05-121-1/+20
| | | | | | | | | | | | | | | | | | | Dynamic GHC is now working in-place, but pathologically slow due to the DLL split. (GHC assumes that all intra-package calls are in the same DLL, but that isn't true when we split the GHC package into 2 DLLs. That means that GHC's startup time is around 22 seconds, as it is doing run-time linking). Also, ghci isn't actually working yet: $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130512: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... <command line>: can't load .so/.DLL for: HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL) ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be found.
* Fix "make 2" in ghc/Ian Lynagh2013-04-211-3/+12
| | | | The ghc-stage1_INPLACE variable wasn't being defined
* Use different exeext variables for each stage; fixes #7709Ian Lynagh2013-04-201-1/+1
| | | | | Currently they are all set to the same value, but when cross-compiling they could be set to different values.
* Follow build system changes in integer-gmpIan Lynagh2013-04-201-2/+4
| | | | Also a couple of other fixes and sanity checks along the way.
* Remove some commented out build system codeIan Lynagh2013-03-191-11/+0
|
* Partial support for dynamic ghc on WindowsIan Lynagh2013-03-161-1/+9
|
* 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-8/+12
| | | | | | | 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).
* Define $(prog)_INPLACE variables automatically, and start using themIan Lynagh2013-03-031-5/+11
|
* Rename $(Windows) to $(Windows_Host)Ian Lynagh2013-03-011-2/+2
|
* Make the build system use -dynamic-too if both way v and dyn are being builtIan Lynagh2013-02-221-0/+2
|
* Separate the non-way-specific hs-suffix rulesIan Lynagh2013-02-211-0/+2
| | | | This means we don't define them multiple times
* Split non-way-specific variables off from distdir-way-opts into distdir-optsIan Lynagh2013-02-211-0/+1
| | | | | The hsc2hs, alex and happy options variables are now also non-way-specific, as the files are shared between all ways.
* Rename hs-suffix-rules to hs-suffix-way-rulesIan Lynagh2013-02-211-1/+1
|
* Finish removing BootingFromHcIan Lynagh2013-02-171-3/+0
|
* Build the stage0 ghc-pkg with CabalIan Lynagh2013-02-161-3/+3
| | | | | | | 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.
* Add a dependency of program modules on GHC.TopHandlerIan Lynagh2013-02-051-0/+8
| | | | | | | | | | | 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
View Lorry Controller Status