1. 08 Sep, 2015 3 commits
    • thomie's avatar
      Build system: check for inconsistent settings (#10157) · 1b8eca18
      thomie authored
      `configure` currently detects when the docbook and hscolour tools aren't
      available, and instead of failing outright (as it does for missing alex
      and happy), sets some variables in mk/config.mk to tell `make` not to
      build the documentation.
      
      Sometimes, however, you want to really make sure all documentation gets
      built, fully colourized. For example when making a release. To do so,
      you can override the mentioned variables from mk/config.mk in
      mk/build.mk (e.g. set HSCOLOUR_SRCS=YES).
      
      This patch adds some error checking to make sure that doing so will not
      result in weird build failures when those tools are still missing.
      
      Test Plan: ran `make` a couple of times, with different mk/config.mk settings.
      
      Reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D1232
      1b8eca18
    • thomie's avatar
      Build system: cleanup BUILD_DIRS + add lots of Notes · 8be43dd9
      thomie authored
      Summary:
      See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
      See Note [Stage1Only vs stage=1] in mk/config.mk.in.
      See Note [No stage2 packages when CrossCompiling or Stage1Only].
      
      Also:
        * use stage2 to build mkUserGuidePart, as was probably intended.
          Now the following represent the same set of packages:
          - packages that we build with ghc-stage2
          - packages that depend on the ghc library
          Those packages are: haddock, mkUserGuidePart and ghctags.
        * don't let utils that don't depend on the ghc library depend on its
          package-data.mk file. Instead, let those utils directly depend on
          the package-data.mk files of the stage1 packages. Not sure if it
          improves anything, but I found it easier to explain what's going on
          this way.
      
      (partially) reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D1218
      8be43dd9
    • thomie's avatar
      Build system: delete the InstallExtraPackages variable · a1586074
      thomie authored
      Just install all packages that are built. Don't make an exception for
      the dph and extra packages.
      
      You can control whether the dph and extra packages should be build using
      the variables BUILD_DPH and BUILD_EXTRA_PKGS. These variables didn't
      exist before. But now that they do, InstallExtraPackages isn't really
      needed anymore.
      
      Reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D1227
      a1586074
  2. 04 Sep, 2015 1 commit
  3. 21 Aug, 2015 1 commit
    • thomie's avatar
      Build system: simplify install.mk.in · 47493e60
      thomie authored
      This will allow fixing #1851 more easily
      ("make install-strip" should work).
      
      This reverts 57e2a81c:
        "On Cygwin, use a Cygwin-style path for /bin/install's destination"
      
      Update submodule haddock and hsc2hs.
      47493e60
  4. 17 Jul, 2015 1 commit
  5. 13 Jul, 2015 3 commits
    • thomie's avatar
      Build system: do not build stm and parallel by default · 392ff06d
      thomie authored
      stm and parallel have an 'extra' tag in the ./packages file, so would get
      added to PACKAGES_STAGE2 by default, and subsequently build by the stage2
      compiler.
      
      With this patch, this happens only when you set BUILD_EXTRA_PKGS=YES in
      build.mk. A normal validate still builds (and tests) the 'extra'
      packages, but they are skipped for `validate --fast`. Maybe this brings
      us closer to finishing within the 50 minute Travis limit as well.
      
      We can later try to give random, primitive and vector an 'extra' tag as
      well (now they have a 'dph' tag), but some tests will probably fail at
      first.
      
      Differential Revision: https://phabricator.haskell.org/D1065
      392ff06d
    • thomie's avatar
      Build system: delete REGULAR_INSTALL_DYNLIBS and INSTALL_DYNLIBS · 47ebe267
      thomie authored
      Ever since we ship xhtml, terminfo and haskeline (#8919), commit
      4caadb7c, REGULAR_INSTALL_DYNLIBS is
      always empty.
      
      REGULAR_INSTALL_PACKAGES =
        PACKAGES_STAGE1 + compiler + PACKAGES_STAGE2
      
      REGULAR_INSTALL_DYNLIBS =
        PACKAGES_STAGE1 + PACKAGES_STAGE2 - REGULAR_INSTALL_PACKAGES
      
      So we can delete it, and all the places where it is used. This
      simplifies ghc.mk a bit.
      
      Differential Revision: https://phabricator.haskell.org/D1062
      47ebe267
    • thomie's avatar
      Build system: comments only [skip ci] · 2e52057a
      thomie authored
      2e52057a
  6. 02 Jul, 2015 1 commit
  7. 22 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Rename $1_$2_$3_LIB_NAME to LIB_FILE. · 01f7e440
      Edward Z. Yang authored
      Summary:
      When we introduced user-friendly library names
      (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
      unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
      be written out by ghc-cabal, $1_$2_LIB_NAME.
      
      What I didn't realize at the time was that this conflicts
      with an existing variable in the build system, $1_$2_$3_LIB_NAME,
      which (confusingly) refers to something like
      'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
      confusing (despite never conflicting), so I renamed this variable
      to LIB_FILE for enhanced greppability.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1002
      01f7e440
  8. 20 Jun, 2015 1 commit
  9. 09 Jun, 2015 2 commits
    • thomie's avatar
      make sdist: distclean testsuite for real (#10406) · 5828457d
      thomie authored
      5828457d
    • Austin Seipp's avatar
      build: Clean testsuite before sdist · a48167ea
      Austin Seipp authored
      When making the `sdist` tarball, we don't really need anything inside
      $(TOP)/testsuite in order to do our thing. So make sure we clean it
      first to avoid situations like #10406.
      
      With D917 landed, this can actually avoided entirely by fixing the
      official release process to instead build an `sdist` //first// from the
      clean git repository and then build that (to fixpoint) and test it. Then
      the originall clean tarball can be shipped.
      
      But it's nice to be safe in the general case where someone might want to
      (in the future) `sdist` out of their build tree.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Reviewed By: thomie
      
      Differential Revision: https://phabricator.haskell.org/D956
      
      GHC Trac Issues: #10406
      a48167ea
  10. 04 Jun, 2015 1 commit
    • thomie's avatar
      Build: ./boot && ./configure && make sdist (#8723) · 092082e7
      thomie authored
      Make it possible to run `make sdist` right after configure, without completing
      a complete build first.
      
      Test Plan:
      I compared the contents of the created `.tar.bz2` files in the `sdistprep`
      directory, after running `make sdist` both before and after completing a full
      build, using `diff -r`. There weren't any differences (after applying the
      patches from D914).
      
      Note that the `.tar.bz2` files were not exactly the same size, but they aren't
      either when tarring and bzipping the same directory twice. It seems tarring
      and bzipping is not deterministic (on my system).
      
      Differential Revision: https://phabricator.haskell.org/D917
      092082e7
  11. 02 Jun, 2015 1 commit
  12. 30 May, 2015 6 commits
  13. 11 May, 2015 1 commit
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · f16ddcee
      Edward Z. Yang authored
      Summary:
      This commit adds stage 1 support for Template Haskell
      quoting, e.g. [| ... expr ... |], which is useful
      for authors of quasiquoter libraries that do not actually
      need splices.  The TemplateHaskell extension now does not
      unconditionally fail; it only fails if the renamer encounters
      a splice that it can't run.
      
      In order to make sure the referenced data structures
      are consistent, template-haskell is now a boot library.
      There are some minor BC changes to template-haskell to make it boot
      on GHC 7.8.
      
      Note for reviewer: big diff changes are simply code
      being moved out of an ifdef; there was no other substantive
      change to that code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D876
      
      GHC Trac Issues: #10382
      f16ddcee
  14. 09 May, 2015 2 commits
    • Edward Z. Yang's avatar
      Revert stage 1 template-haskell. This is a combination of 5 commits. · 5c459eef
      Edward Z. Yang authored
      Revert "Quick fix: drop base bound on template-haskell."
      
      This reverts commit 3c70ae03.
      
      Revert "Always do polymorphic typed quote check, c.f. #10384"
      
      This reverts commit 9a43b2c1.
      
      Revert "RnSplice's staging test should be applied for quotes in stage1."
      
      This reverts commit eb0ed403.
      
      Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler."
      
      This reverts commit 21c72e7d.
      
      Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382."
      
      This reverts commit 28257cae.
      5c459eef
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · 28257cae
      Edward Z. Yang authored
      Summary:
      This commit adds stage 1 support for Template Haskell
      quoting, e.g. [| ... expr ... |], which is useful
      for authors of quasiquoter libraries that do not actually
      need splices.  The TemplateHaskell extension now does not
      unconditionally fail; it only fails if the renamer encounters
      a splice that it can't run.
      
      In order to make sure the referenced data structures
      are consistent, template-haskell is now a boot library.
      
      In the following patches, there are:
      
          - A few extra safety checks which should be enabled
            in stage1
          - Separation of the th/ testsuite into quotes/ which
            can be run on stage1
      
      Note for reviewer: big diff changes are simply code
      being moved out of an ifdef; there was no other substantive
      change to that code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D876
      
      GHC Trac Issues: #10382
      28257cae
  15. 03 Apr, 2015 1 commit
  16. 02 Apr, 2015 1 commit
    • thomie's avatar
      Disable same warnings for normal builds as for validate (#10223) · 4c1e1c87
      thomie authored
      The default validate settings currently disable some warnings in the
      libraries. This patch moves those settings to a new file called
      `mk/warnings.mk`, and applies them also to normal builds.
      
      Through uncommenting a line in build.mk, developers can now build with
      -Werror.
      
      -Werror is not the default, because:
      * We can not guarantee that the build is warning free on platforms we
        don't run regularly run validate (as part of continuous integration
        systems), and we still want the build to go through on those
        platforms.
      * quoting rwbarton on irc > "I think -Werror by default has come up in
        the past and the argument was that it is too annoying when you are
        doing nontrivial development"
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D785
      4c1e1c87
  17. 31 Mar, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Drop old integer-gmp-0.5 from GHC source tree · 995e8c1c
      Herbert Valerio Riedel authored
      This completes what c774b28f (#9281)
      started.  `integer-gmp-1.0` was added as an additional
      `libraries/integer-gmp2` folder while retaining the ability to configure
      GHC w/ the old `integer-gmp-0.5` to have a way back, and or the ability
      to easily switch between old/new `integer-gmp` for benchmark/debugging
      purposes.
      
      This commit removes the old `libraries/integer-gmp` folder and moves
      `libraries/integer-gmp2` into its place, while removing any mentions of
      "gmp2" as well as the to support two different `integer-gmp` packages in
      GHC's source-tree.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D769
      995e8c1c
  18. 23 Feb, 2015 3 commits
  19. 27 Dec, 2014 1 commit
  20. 23 Dec, 2014 1 commit
  21. 28 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Improve VERSION/GIT_COMMIT_ID handling for sdist · 7dd4c12c
      Herbert Valerio Riedel authored
      This makes `VERSION` updating a bit more robust (the file gets only
      updated if its content would actually change), as well as moving the
      dependency of `VERSION` and `GIT_COMMIT_ID` to the `sdist-ghc-prep`
      target, as that's where it's actually needed.
      
      This fixes the specialised target `make sdist-ghc` not properly
      creating/updating the `VERSION` and `GIT_COMMIT_ID` files before
      creating the ghc source-dist tarball, as well as avoiding stale
      `VERSION` files.
      7dd4c12c
  22. 27 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Embed Git commit id into `ghc --info` output · 73e5e2f8
      Herbert Valerio Riedel authored
      Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
      commit id uniquely identifies the state of the GHC source-tree. So
      having that information embedded into the `ghc` executable provides
      valuable information to track accurately (especially when created by
      buildbots) from which source-tree-state a given `ghc` snapshot
      (distribution) was generated.
      
      So this commit adds a new field `"Project Git commit id"` to the
      `ghc --info` meta-data containing the `./configure`-time Git commit id
      as reported by `git rev-parse HEAD`.
      
      This field can also be queried with `ghc --print-project-git-commit-id`.
      
      For source distributions, the file `GIT_COMMIT_ID` is created (with some
      sanity checking to detect stale commit ids, as that would render this
      information rather useless)
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D528
      73e5e2f8
  23. 21 Nov, 2014 1 commit
  24. 18 Nov, 2014 1 commit
  25. 12 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement new integer-gmp2 from scratch (re #9281) · c774b28f
      Herbert Valerio Riedel authored
      This is done as a separate `integer-gmp2` backend library because it
      turned out to become a complete rewrite from scratch.
      
      Due to the different (over)allocation scheme and potentially different
      accounting (via the new `{shrink,resize}MutableByteArray#` primitives),
      some of the nofib benchmarks actually results in increased allocation
      numbers (but not necessarily an increase in runtime!).  I believe the
      allocation numbers could improve if `{resize,shrink}MutableByteArray#`
      could be optimised to reallocate in-place more efficiently.
      
      Here are the more apparent changes in the latest nofib comparision
      between `integer-gmp` and `integer-gmp2`:
      
        ------------------------------------------------------------------
                Program     Size    Allocs   Runtime   Elapsed  TotalMem
        ------------------------------------------------------------------
                    ...
             bernouilli    +1.6%    +15.3%     0.132     0.132      0.0%
                    ...
           cryptarithm1    -2.2%      0.0%     -9.7%     -9.7%      0.0%
                    ...
                  fasta    -0.7%     -0.0%    +10.9%    +10.9%      0.0%
                    ...
                  kahan    +0.6%    +38.9%     0.169     0.169      0.0%
                    ...
                   lcss    -0.7%     -0.0%     -6.4%     -6.4%      0.0%
                    ...
                 mandel    +1.6%    +33.6%     0.049     0.049      0.0%
                    ...
               pidigits    +0.8%     +8.5%     +3.9%     +3.9%      0.0%
                  power    +1.4%    -23.8%    -18.6%    -18.6%    -16.7%
                    ...
              primetest    +1.3%    +50.1%     0.085     0.085      0.0%
                    ...
                    rsa    +1.6%    +53.4%     0.026     0.026      0.0%
                    ...
                    scs    +1.2%     +6.6%     +6.5%     +6.6%    +14.3%
                    ...
                 symalg    +1.0%     +9.5%     0.010     0.010      0.0%
                    ...
              transform    -0.6%     -0.0%     -5.9%     -5.9%      0.0%
                    ...
        ------------------------------------------------------------------
                    Min    -2.3%    -23.8%    -18.6%    -18.6%    -16.7%
                    Max    +1.6%    +53.4%    +10.9%    +10.9%    +14.3%
         Geometric Mean    -0.3%     +1.9%     -0.8%     -0.8%     +0.0%
      
      (see P35 / https://phabricator.haskell.org/P35 for full report)
      
      By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results
      in the package `integer-gmp-1.0.0.0` being registered in the package db.
      The previous `integer-gmp-0.5.1.0` can be restored by setting
      `INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether
      for GHC 7.12). In-tree GMP support has been stolen from the old
      `integer-gmp` (while unpatching the custom memory-allocators, as well as
      forcing `-fPIC`)
      
      A minor hack to `ghc-cabal` was necessary in order to support two different
      `integer-gmp` packages (in different folders) with the same package key.
      
      There will be a couple of follow-up commits re-implementing some features
      that were dropped to keep D82 minimal, as well as further
      clean-ups/improvements.
      
      More information can be found via #9281 and
      https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2
      
      Reviewed By: austin, rwbarton, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D82
      c774b28f
  26. 07 Nov, 2014 1 commit
    • rodlogic's avatar
      small parser/lexer cleanup · 37d64a51
      rodlogic authored
      Summary:
      The last three '#define ...' macros were removed from Parser.y.pp and this file was renamed to Parser.y.
      This basically got rid of a CPP step in the build.
      
      Also converted two modules in compiler/parser/ from .lhs to .hs.
      
      Test Plan: Does it build? Yes, I performed a full build here and things are looking good.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: adamse, thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D411
      37d64a51
  27. 05 Oct, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `MIN_VERSION_GLASGOW_HASKELL()` macro · 3549c952
      Herbert Valerio Riedel authored
      This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
      allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
      would result in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
        #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
      
      while GHC 7.10.3 results in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
      
      and finally GHC 7.9.20141009 results in
      
        #define __GLASGOW_HASKELL__             709
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
      
      As it's error-prone to properly express CPP conditionals for testing GHC
      multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
      provided (also via the new CPP include file `ghcversion.h`)
      
      Finally, in order to make it easier to define the new CPP macro
      `MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
      `include/ghcversion.h` is used for the new CPP definitions.
      
      Reviewed By: ekmett, austin, #ghc
      
      Differential Revision: https://phabricator.haskell.org/D66
      3549c952