1. 29 Mar, 2016 21 commits
  2. 28 Mar, 2016 7 commits
    • Herbert Valerio Riedel's avatar
      Remove obsolete --with-hc flag from ./configure · cd3fbff9
      Herbert Valerio Riedel authored
      This was probably missed during the big build-system refactoring in
    • Herbert Valerio Riedel's avatar
      Update bytestring submodule to latest snapshot · eb25381d
      Herbert Valerio Riedel authored
      Most notably, this pulls in the following changes
      > Fix breakByte and spanByte rewrite rules
      > Implement `stripPrefix`/`stripSuffix`
      The first patch is related to #11688
    • kaiha's avatar
      Do not test for existence of the executable · 49b9d80a
      kaiha authored
      The test for the existence of the executable breaks on MS Windows. It is
      furthermore needless, because if the test can be executed the executable
      is obviously there.
      Reviewers: austin, bgamari, Phyx
      Reviewed By: Phyx
      Subscribers: Phyx, thomie
      Differential Revision: https://phabricator.haskell.org/D2050
      GHC Trac Issues: #4114
    • Herbert Valerio Riedel's avatar
      Autoconf: detect and set CFLAGS/CPPFLAGS needed for C99 mode · afc48f89
      Herbert Valerio Riedel authored
      This is the first phase of addressing #11757 which aims to make C99
      support a base-line requirement for GHC and clean up the code-base to
      use C99 facilities when sensible.
      This patch exploits the logic/heuristic used by `AC_PROG_CC_C99` to
      determine the flags needed in case the C compiler isn't able to compile
      C99 code in its current mode. We can't use `AC_PROG_CC_C99` directly
      though because GHC's build-system expects CC to contain a filename
      without any flags, while `AC_PROG_CC_C99` would e.g. result in
      `CC="gcc -std=gnu99"`. Morever, we support different `CC`s for
      stage0/1/2, so we need a version of `AC_PROG_CC_C99` for which we can
      specify the `CC`/`CFLAGS` variables to operate on. This is what
      `FP_SET_CFLAGS_C99` does.
      Note that Clang has been defaulting to C99+ for a long time, while GCC 5
      defaults to C99+ as well. So this has mostly an affect on older GCCs
      versions prior to 5.0 and possibly compilers other than GCC/Clang (which
      are not officially supported for building GHC anyway).
      Reviewers: kgardas, erikd, bgamari, austin
      Reviewed By: erikd
      Differential Revision: https://phabricator.haskell.org/D2045
    • Herbert Valerio Riedel's avatar
      Drop Xcode 4.1 hack and fix ignored CC var issue · ffc802e8
      Herbert Valerio Riedel authored
      Xcode 4.1 was released back in 2011 for Mac OSX 10.6/10.7.
      However, OSX 10.7 reached EOL sometime around the end of 2014.
      So this `--with-gcc-4.2` hack shouldn't be needed anymore.
      Moreover, this patch changes ./configure to honor the CC env-var
      again (and thus fix #11231) while giving `--with-gcc=...` a higher
      priority over `CC=...`.
      So the following 3 invocations are equivalent now:
        CC=... ./configure
        ./configure CC=...
        ./configure --with-gcc=...
      Since `--with-{gcc,clang}=...` is a misnomer (as is made apparent by
      `--with-gcc=clang` or `--with-clang=gcc`), this would give us a neutral
      and idiomatic way to tell ./configure which C compiler to use.
      Moreover, `./configure --help` says at the end of its output:
        Some influential environment variables:
          CC		C compiler command
          CFLAGS	C compiler flags
          LDFLAGS	linker flags, e.g. -L<lib dir> if you have libraries in a
      		nonstandard directory <lib dir>
          LIBS	libraries to pass to the linker, e.g. -l<library>
          CPPFLAGS	(Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
      		you have headers in a nonstandard directory <include dir>
          CPP		C preprocessor
        Use these variables to override the choices made by `configure' or to help
        it to find libraries and programs with nonstandard names/locations.
      Consequently, by honoring CC=... (rather than ignoring it) we increase
      consistency and reduce user confusion. Ideally, CC=... would become the
      recommended way to set the C compiler, and `--with-{clang,gcc}=...`
      would be demoted to legacy aliases.
      Reviewed By: erikd, bgamari
      Differential Revision: https://phabricator.haskell.org/D2046
    • Herbert Valerio Riedel's avatar
      Scrap DEC OSF/1 support · f911358b
      Herbert Valerio Riedel authored
      DEC OSF/1 (aka Tru64 UNIX) has been discontinued a few years ago already[1].
      This removes the undoubtedly bitrotten support for `OSOsf3 :: OS` from GHC's
      Support for `ArchAlpha :: Arch` may be removed at some later point, as there
      may still be users out there running a more or less recent Linux/alpha
      distribution on their more-than-a-decade old Alpha hardware...
       [1]: https://en.wikipedia.org/wiki/Tru64_UNIX
    • Herbert Valerio Riedel's avatar
      Scrap IRIX support · 0bca3f3a
      Herbert Valerio Riedel authored
      Long time ago, IRIX was way ahead of its time in the last century with
      its SMP capabilities of scaling up to 1024 processors and other features
      such as XFS or OpenGL that originated in IRIX and live on to this day in
      other operating systems.
      However, IRIX's last software update was in 2006 and support ended
      around 2013 according to [1], so it's considered an extinct platform by
      now. So this commit message is effectively an obituary for GHC's IRIX
      R.I.P. IRIX
       [1]: https://en.wikipedia.org/wiki/IRIX
  3. 27 Mar, 2016 3 commits
  4. 26 Mar, 2016 3 commits
  5. 25 Mar, 2016 6 commits