summaryrefslogtreecommitdiff
path: root/mk
Commit message (Collapse)AuthorAgeFilesLines
* Bump win32-tarballs version to 0.3Ben Gamari2020-10-091-1/+1
| | | | This should fix #18774.
* Enable TICKY_TICKY for debug builds when building with makefiles.David Himmelstrup2020-09-111-2/+2
|
* [macOS] improved runpath handlingMoritz Angermann2020-09-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In b592bd98ff25730bbe3c13d6f62a427df8c78e28 we started using -dead_strip_dylib on macOS when lining dynamic libraries and binaries. The underlying reason being the Load Command Size Limit in macOS Sierra (10.14) and later. GHC will produce @rpath/libHS... dependency entries together with a corresponding RPATH entry pointing to the location of the libHS... library. Thus for every library we produce two Load Commands. One to specify the dependent library, and one with the path where to find it. This makes relocating libraries and binaries easier, as we just need to update the RPATH entry with the install_name_tool. The dynamic linker will then subsitute each @rpath with the RPATH entries it finds in the libraries load commands or the environement, when looking up @rpath relative libraries. -dead_strip_dylibs intructs the linker to drop unused libraries. This in turn help us reduce the number of referenced libraries, and subsequently the size of the load commands. This however does not remove the RPATH entries. Subsequently we can end up (in extreme cases) with only a single @rpath/libHS... entry, but 100s or more RPATH entries in the Load Commands. This patch rectifies this (slighly unorthodox) by passing *no* -rpath arguments to the linker at link time, but -headerpad 8000. The headerpad argument is in hexadecimal and the maxium 32k of the load command size. This tells the linker to pad the load command section enough for us to inject the RPATHs later. We then proceed to link the library or binary with -dead_strip_dylibs, and *after* the linking inspect the library to find the left over (non-dead-stripped) dependencies (using otool). We find the corresponding RPATHs for each @rpath relative dependency, and inject them into the library or binary using the install_name_tool. Thus achieving a deadstripped dylib (and rpaths) build product. We can not do this in GHC, without starting to reimplement a dynamic linker as we do not know which symbols and subsequently libraries are necessary. Commissioned-by: Mercury Technologies, Inc. (mercury.com)
* configure: Avoid hard-coded ld path on WindowsGHC GitLab CI2020-09-041-0/+10
| | | | | | | The fix to #17962 ended up regressing on Windows as it failed to replicate the logic responsible for overriding the toolchain paths on Windows. This resulted in a hard-coded path to a directory that likely doesn't exist on the user's system (#18550).
* document how build system find toolchains on WindowsTamar Christina2020-08-281-0/+1
|
* Fix use distro toolchianTamar Christina2020-08-281-2/+3
|
* Refactor handling of object mergingBen Gamari2020-08-051-1/+2
| | | | | | | | | Previously to merge a set of object files we would invoke the linker as usual, adding -r to the command-line. However, this can result in non-sensical command-lines which causes lld to balk (#17962). To avoid this we introduce a new tool setting into GHC, -pgmlm, which is the linker which we use to merge object files.
* Replace ghcWithNativeCodeGen with a proper Backend datatypeSylvain Henry2020-07-221-13/+0
| | | | | | | | | | | | | | | | * Represent backends with a `Backend` datatype in GHC.Driver.Backend * Don't detect the default backend to use for the target platform at compile time in Hadrian/make but at runtime. It makes "Settings" simpler and it is a step toward making GHC multi-target. * The latter change also fixes hadrian which has not been updated to take into account that the NCG now supports AIX and PPC64 (cf df26b95559fd467abc0a3a4151127c95cb5011b9 and d3c1dda60d0ec07fc7f593bfd83ec9457dfa7984) * Also we don't treat iOS specifically anymore (cf cb4878ffd18a3c70f98bdbb413cd3c4d1f054e1f)
* get-win32-tarballs: Fix detection of missing tarballsBen Gamari2020-07-221-1/+3
| | | | | This fixes the error message given by configure when the user attempts to configure without first download the win32 tarballs.
* hadrian/make: Detect makeindexBen Gamari2020-06-251-0/+1
| | | | | | Previously we would simply assume that makeindex was available. Now we correctly detect it in `configure` and respect this conclusion in hadrian and make.
* Update `make` based build systemSylvain Henry2020-06-178-10/+10
| | | | * replace integer-* package selection with ghc-bignum backend selection
* Clean up file paths for new module hierarchyTakenobu Tani2020-06-011-3/+3
| | | | | | | | | This updates comments only. This patch replaces file references according to new module hierarchy. See also: * https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular * https://gitlab.haskell.org/ghc/ghc/issues/13009
* Windows: Bump Windows toolchain to 0.2Ben Gamari2020-05-301-1/+1
|
* Build a threaded stage 1 if the bootstrapping GHC supports it.Travis Whitaker2020-05-291-0/+3
|
* get-win32-tarballs: Improve diagnostics outputBen Gamari2020-05-131-2/+8
|
* get-win32-tarballs: Fix base URLBen Gamari2020-05-131-1/+0
| | | | Revert a change previously made for testing purposes.
* Kill wORDS_BIGENDIAN and replace it with platformByteOrder (#17957)Sylvain Henry2020-04-011-0/+1
| | | | | | Metric Decrease: T13035 T1969
* Modules: Driver (#13009)Sylvain Henry2020-02-211-1/+1
| | | | submodule updates: nofib, haddock
* Rework handling of win32 toolchain tarballsBen Gamari2020-02-142-326/+59
|
* Add two warnings to stage 2 buildTom Ellis2020-01-271-1/+1
|
* Fix more typos, via an improved Levenshtein-style correctorBrian Wignall2020-01-122-2/+2
|
* Fix typos, via a Levenshtein-style correctorBrian Wignall2020-01-041-1/+1
|
* Fix typos, using Wikipedia list of common typosBrian Wignall2019-11-281-1/+1
|
* Properly account for libdw paths in make build systemBen Gamari2019-11-191-0/+1
| | | | Should finally fix #17255.
* configure: Add --with-libdw-{includes,libraries} flagsBen Gamari2019-11-061-0/+3
| | | | Fixing #17255.
* distrib: Fix binary distribution installationBen Gamari2019-10-291-1/+2
| | | | | This had silently regressed due to 81860281 and the variable renaming performed in b55ee979, as noted in #17374.
* Don't substitute GccVersion variableBen Gamari2019-10-291-2/+0
| | | | | Not only is it now unused but we generally can't assume that we are compiling with GCC, so it really shouldn't be used.
* configure: Drop GccLT46Ben Gamari2019-10-252-3/+0
| | | | | GCC 4.6 was released 7 years ago. I think we can finally assume that it's available. This is a simplification prompted by #15742.
* Implement s390x LLVM backend.Stefan Schulze Frielinghaus2019-10-221-2/+2
| | | | | | This patch adds support for the s390x architecture for the LLVM code generator. The patch includes a register mapping of STG registers onto s390x machine registers which enables a registerised build.
* Windows: Update tarballs to GCC 9.2 and remove MAX_PATH limit.Tamar Christina2019-10-202-61/+126
|
* Simplify Configure in a few waysJohn Ericson2019-10-123-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - No need to distinguish between gcc-llvm and clang. First of all, gcc-llvm is quite old and surely unmaintained by now. Second of all, none of the code actually care about that distinction! Now, it does make sense to consider C multiple frontends for LLVMs in the form of clang vs clang-cl (same clang, yes, but tweaked interface). But this is better handled in terms of "gccish vs mvscish" and "is LLVM", yielding 4 combinations. Therefore, I don't think it is useful saving the existing code for that. - Get the remaining CC_LLVM_BACKEND, and also TABLES_NEXT_TO_CODE in mk/config.h the normal way, rather than hacking it post-hoc. No point keeping these special cases around for now reason. - Get rid of hand-rolled `die` function and just use `AC_MSG_ERROR`. - Abstract check + flag override for unregisterised and tables next to code. Oh, and as part of the above I also renamed/combined some variables where it felt appropriate. - GccIsClang -> CcLlvmBackend. This is for `AC_SUBST`, like the other Camal case ones. It was never about gcc-llvm, or Apple's renamed clang, to be clear. - llvm_CC_FLAVOR -> CC_LLVM_BACKEND. This is for `AC_DEFINE`, like the other all-caps snake case ones. llvm_CC_FLAVOR was just silly indirection *and* an odd name to boot.
* Get rid of GHC_PACKAGE_DB_FLAGJohn Ericson2019-10-071-2/+0
| | | | | We no longer support booting from older GHC since 527bcc41630918977c73584d99125ff164400695.
* Remove CONFIGURE_ARGS from configure.acJohn Ericson2019-10-071-8/+0
| | | | | It looks like it's been unused since at least 34cc75e1a62638f2833815746ebce0a9114dc26b.
* Factor out a smaller part of Platform for host fallbackJohn Ericson2019-10-041-0/+2
|
* Make sure all boolean settings entries use `YES` / `NO`John Ericson2019-09-051-5/+4
| | | | | | | | | Some where using `True` / `False`, a legacy of when they were in `Config.hs`. See #16914 / d238d3062a9858 for a similar problem. Also clean up the configure variables names for consistency and clarity while we're at it. "Target" makes clear we are talking about outputted code, not where GHC itself runs.
* Consolidate `TablesNextToCode` and `GhcUnreigsterised` in configure (#15548)Joachim Breitner2019-08-101-11/+1
| | | | | | | | | | | | | | | | | | | | `TablesNextToCode` is now a substituted by configure, where it has the correct defaults and error handling. Nowhere else needs to duplicate that, though we may want the compiler to to guard against bogus settings files. I renamed it from `GhcEnableTablesNextToCode` to `TablesNextToCode` to: - Help me guard against any unfixed usages - Remove any lingering connotation that this flag needs to be combined with `GhcUnreigsterised`. Original reviewers: Original subscribers: TerrorJack, rwbarton, carter Original Differential Revision: https://phabricator.haskell.org/D5082
* gitlab-ci: Fix doc-tarball jobBen Gamari2019-07-031-2/+2
| | | | | | | Previously we used the deb9-debug job which used the `validate` build flavour which disabled `BUILD_SPHINX_PDF`. Fix this. Fixes #16890.
* Disable optimisation when building Cabal in development flavoursBen Gamari2019-06-153-0/+13
| | | | | | | | | | This updates the make and Hadrian build flavours targetting developers to disable optimisation when building the Cabal library. Cabal tends to tickle some very bad compiler performance cases (e.g. #16577) so disabling optimisation here makes a sizeable impact on overall build time. See #16817.
* Maintain separate flags for C++ compiler invocationsBen Gamari2019-06-131-0/+1
| | | | | | | Previously we would pass flags intended for the C compiler to the C++ compiler (see #16738). This would cause, for instance, `-std=gnu99` to be passed to the C++ compiler, causing spurious test failures. Fix this by maintaining a separate set of flags for C++ compilation invocations.
* Add `-haddock` to prepare-system.sh and .gitlab-ci.ymlTakenobu Tani2019-06-021-1/+1
| | | | | | To cover ci conditions from ghc8.6 to 8.9, I add `-haddock` option to `.circleci/prepare-system.sh` and .gitlab-ci.yml. after including `mk/flavours/*`.
* Add `-haddock` to perf.mk rather than prepare-system.shTakenobu Tani2019-06-021-1/+1
| | | | | | | | | | To cover ci conditions from ghc8.6 to 8.9, I add `-haddock` option to `mk/flavours/perf.mk` rather than `.circleci/prepare-system.sh`. Because in windows condition of ghc-8.9, `mk/flavours/*` is included after `prepare-system.sh`. In addition, in linux condition of ghc-8.6, `mk/flavors/perf.mk` is used.
* Restore the --coerce option in 'happy' configurationVladislav Zavialov2019-05-141-2/+1
| | | | | | happy-1.19.10 has been released with a fix for --coerce in the presence of higher rank types. This should result in about 10% performance improvement in the parser.
* Generate settings by make/hadrian instead of configureJohn Ericson2019-04-301-0/+37
| | | | This allows it to eventually become stage-specific
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-255-6/+6
| | | | | | | | | | | | | | | | | | | | | | | 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
* gitlab-ci: Explicitly set bindist tarball nameBen Gamari2019-03-161-6/+6
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-153-3/+3
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Rip out perl dependencyBen Gamari2019-03-093-3/+0
| | | | | | The object splitter was the last major user of perl. There remain a few uses in nofib but we can just rely on the system's perl for this since it's not critical to the build.
* Rip out object splittingBen Gamari2019-03-0519-49/+1
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* gitlab-ci: Produce DWARF-enabled binary distributionBen Gamari2019-03-011-0/+14
|
* Expression/command ambiguity resolutionVladislav Zavialov2019-02-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by introducing a new ambiguity resolution system in the parser. Problem: there are places in the grammar where we do not know whether we are parsing an expression or a command: proc x -> do { (stuff) -< x } -- 'stuff' is an expression proc x -> do { (stuff) } -- 'stuff' is a command Until we encounter arrow syntax (-<) we don't know whether to parse 'stuff' as an expression or a command. The old solution was to parse as HsExpr always, and rejig later: checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs) This meant polluting 'HsExpr' with command-related constructors. In other words, limitations of the parser were affecting the AST, and all other code (the renamer, the typechecker) had to deal with these extra constructors by panicking. We fix this abstraction leak by parsing into an intermediate representation, 'ExpCmd': data ExpCmdG b where ExpG :: ExpCmdG HsExpr CmdG :: ExpCmdG HsCmd type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs)) checkExp :: ExpCmd -> PV (LHsExpr GhcPs) checkCmd :: ExpCmd -> PV (LHsCmd GhcPs) checkExp f = f ExpG -- interpret as an expression checkCmd f = f CmdG -- interpret as a command See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/command ambiguity. Future work: apply the same principles to the expression/pattern ambiguity.
View Lorry Controller Status