1. 04 Oct, 2015 1 commit
  2. 03 Oct, 2015 2 commits
  3. 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
  4. 04 Sep, 2015 1 commit
  5. 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
  6. 17 Jul, 2015 1 commit
  7. 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
  8. 02 Jul, 2015 1 commit
  9. 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
  10. 20 Jun, 2015 1 commit
  11. 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
  12. 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
  13. 02 Jun, 2015 1 commit
  14. 30 May, 2015 6 commits
  15. 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
  16. 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
  17. 03 Apr, 2015 1 commit
  18. 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
  19. 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
  20. 23 Feb, 2015 3 commits
  21. 27 Dec, 2014 1 commit
  22. 23 Dec, 2014 1 commit
  23. 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
  24. 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
  25. 21 Nov, 2014 1 commit
  26. 18 Nov, 2014 1 commit