summaryrefslogtreecommitdiff
path: root/mk
Commit message (Collapse)AuthorAgeFilesLines
* hadrian: Don't rely on realpath in bindist MakefileBen Gamari2021-12-021-0/+53
| | | | | | | | As noted in #19963, `realpath` is not specified by POSIX and therefore cannot be assumed to be available. Here we provide a POSIX shell implementation of `realpath`, due to Julian Ospald and others. Closes #19963.
* Make ambient MinGW support a proper settingsJohn Ericson2021-11-272-1/+1
| | | | | | | Get rid of `USE_INPLACE_MINGW_TOOLCHAIN` and use a settings file entry instead. The CPP setting was originally introduced in f065b6b012.
* Make: Get rid of GHC_INCLUDE_DIRSJohn Ericson2021-11-151-1/+0
| | | | | | These dirs should not be included in all stages. Instead make the per-stage `BUILD_*_INCLUDE_DIR` "plural" to insert `rts/include` in the right place.
* Make: Install RTS headers in `$libdir/rts/include` not `$libdir/include`John Ericson2021-11-121-1/+1
| | | | | | | Before we were violating the convention of every other package. This fixes that. It matches the changes made in d5de970dafd5876ef30601697576167f56b9c132 to the location of the files in the repo.
* Make build system: Put make generated include's in RTS distdirsJohn Ericson2021-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are best thought of as being part of the RTS. - After !6791, `ghcautoconf.h` won't be used by the compiler inappropriately. - `ghcversion.h` is only used once outside the RTS, which is `compiler/cbits/genSym.c`. Except we *do* mean the RTS GHC is built against there, so it's better if we always get get the installed version. - `ghcplatform.h` alone is used extensively outside the RTS, but since we no longer have a target platform it is perfectly safe/correct to get the info from the previous RTS. All 3 are exported from the RTS currently and in the bootstrap window. This commit just swaps directories around, such that the new headers may continue to be used in stage 0 despite the reasoning above, but the idea is that we can subsequently make more interesting changes doubling down on the reasoning above. In particular, in !6803 we'll start "morally" moving `ghcautonconf.h` over, introducing an RTS configure script and temporary header of its `AC_DEFINE`s until the top-level configure script doesn't define any more. Progress towards #17191
* Remove stray reference to `dist-ghcconstants`John Ericson2021-10-251-1/+1
| | | | | I think this hasn't been a thing since 86054b4ab5125a8b71887b06786d0a428539fb9c, almost 10 years ago!
* Link with libm dynamically (#19877)Sylvain Henry2021-09-221-0/+1
| | | | The compiler should be independent of the target.
* Move `/includes` to `/rts/include`, sort per package betterJohn Ericson2021-08-092-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make the packages in this repo "reinstallable", we need to associate source code with a specific packages. Having a top level `/includes` dir that mixes concerns (which packages' includes?) gets in the way of this. To start, I have moved everything to `rts/`, which is mostly correct. There are a few things however that really don't belong in the rts (like the generated constants haskell type, `CodeGen.Platform.h`). Those needed to be manually adjusted. Things of note: - No symlinking for sake of windows, so we hard-link at configure time. - `CodeGen.Platform.h` no longer as `.hs` extension (in addition to being moved to `compiler/`) so as not to confuse anyone, since it is next to Haskell files. - Blanket `-Iincludes` is gone in both build systems, include paths now more strictly respect per-package dependencies. - `deriveConstants` has been taught to not require a `--target-os` flag when generating the platform-agnostic Haskell type. Make takes advantage of this, but Hadrian has yet to.
* rts: Break up adjustor logicBen Gamari2021-07-271-10/+2
|
* Adds AArch64 Native Code GeneratorMoritz Angermann2021-06-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In which we add a new code generator to the Glasgow Haskell Compiler. This codegen supports ELF and Mach-O targets, thus covering Linux, macOS, and BSDs in principle. It was tested only on macOS and Linux. The NCG follows a similar structure as the other native code generators we already have, and should therfore be realtively easy to follow. It supports most of the features required for a proper native code generator, but does not claim to be perfect or fully optimised. There are still opportunities for optimisations. Metric Decrease: ManyAlternatives ManyConstructors MultiLayerModules PmSeriesG PmSeriesS PmSeriesT PmSeriesV T10421 T10421a T10858 T11195 T11276 T11303b T11374 T11822 T12227 T12545 T12707 T13035 T13253 T13253-spj T13379 T13701 T13719 T14683 T14697 T15164 T15630 T16577 T17096 T17516 T17836 T17836b T17977 T17977b T18140 T18282 T18304 T18478 T18698a T18698b T18923 T1969 T3064 T5030 T5321FD T5321Fun T5631 T5642 T5837 T783 T9198 T9233 T9630 T9872d T9961 WWRec Metric Increase: T4801
* [bindist] inject xattr -c -r . into the darwin install phaseMoritz Angermann2021-05-251-0/+7
| | | | This is so awful, but at least it might get the job done.
* Remove dynamic-by-default (#16782)Sylvain Henry2021-04-077-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dynamic-by-default was a mechanism to automatically select the -dynamic way for some targets. It was implemented in a convoluted way: it was defined as a flavour option, hence it couldn't be passed as a global settings (which are produced by `configure` before considering flavours), so a build system rule was used to pass -DDYNAMIC_BY_DEFAULT to the C compiler so that deriveConstants could infer it. * Make build system has it disabled for 8 years (951e28c0625ece7e0db6ac9d4a1e61e2737b10de) * It has never been implemented in Hadrian * Last time someone tried to enable it 1 year ago it didn't work (!2436) * Having this as a global constant impedes making GHC multi-target (see !5427) This commit fully removes support for dynamic-by-default. If someone wants to reimplement something like this, it would probably need to move the logic in the compiler. (Doing this would probably need some refactoring of the way the compiler handles DynFlags: DynFlags are used to store and to pass enabled ways to many parts of the compiler. It can be set by command-line flags, GHC API, global settings. In multi-target GHC, we will use DynFlags to load the target platform and its constants: but at this point with the current DynFlags implementation we can't easily update the existing DynFlags with target-specific options such as dynamic-by-default without overriding ways previously set by the user.)
* Implement riscv64 LLVM backendAndreas Schwab2021-03-051-1/+1
| | | | This enables a registerised build for the riscv64 architecture.
* 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.
View Lorry Controller Status