Herbert Valerio Riedel authored 8 years ago and Ben Gamari committed 8 years ago

Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
scheme use the `CC=...` style scheme.

The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
stage{1,2,3}, while having a separate _STAGE0 set of env-vars
denote the bootstrap-toolchain flags/programs.

This should be simpler, less confusing, and somewhat more in line with
Autoconf's idioms (allowing us to reuse more of Autoconf rather than
(re)inventing our own confusing non-standard m4 macros to do stuff that
Autoconf could almost do already for us)

Morever, expose CC_STAGE0 as a so-called "precious" variable.

So now we can better control which bootstrapping gcc is used
(by default the one used by the stage0 ghc, unless CC_STAGE0 is
overriden)

```
Some influential environment variables:
  CC_STAGE0   C compiler command (bootstrap)
  CC          C compiler command
  CFLAGS      C compiler flags
  ...

Use these variables to override the choices made by `configure' or to
help it to find libraries and programs with nonstandard names/locations.
```

Test Plan: I've tested that cross-compiling with
`--target=powerpc-linux-gnu` still works, and tried a few variants of
settting `CC=` and `CC_STAGE0=`; `./validate` passed as well

Reviewers: erikd, austin, bgamari, simonmar

Reviewed By: simonmar

Subscribers: Phyx, thomie

Differential Revision: https://phabricator.haskell.org/D2078

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
support.

R.I.P. IRIX

 [1]: https://en.wikipedia.org/wiki/IRIX

In 3549c952 a `include/ghcversions.h` include
file was introduced which defines `__GLASGOW_HASKELL__` as well.

So there's no need to define it twice.

Herbert Valerio Riedel authored 9 years ago and Ben Gamari committed 9 years ago

`derivedConstants` currently uses `System.Info.os` for decisions (which
doesn't necessarily reflect the build-target), as well as hardcoding
"/usr/bin/objdump" for openbsd.

This patch auto-detects `objdump` similiar to how `nm` is detected via
Autoconf as well as passing the target-os into `derivedConstants` via
commandline.

Reviewers: austin, kgardas, erikd, bgamari

Reviewed By: kgardas, erikd, bgamari

Subscribers: kgardas, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D1499

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.

Today I learned about the peculiarities of escaping within
single-quotes:

Turns out,

  echo 'foo \\'

emits

  foo \\

rather than escaping the '\'. Curiously, if you need to escape a '
within single-quotes, here's how to do it

  echo 'foo '\'' bar'

which will emit

  foo ' bar

This fixes #10002

This typo slipped in through 3549c952

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

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Fixes build on OS X

DeriveConstants.hs works in a cross-compilation-friendly way. Rather
than running a C program that prints out the constants, we just compile
a C file which has the constants are encoded in symbol sizes. We then
parse the output of 'nm' to find out what the constants are.

Based on work by Gabor Greif <ggreif@gmail.com>.

This required various build system changes to get the build to go
through.

In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
to find their libraries. In the future, we might change the inplace tree
to be the same shape as an installed tree instead. However, this would
mean changing the way we do installation, as currently we use cabal's
installation methods to install the libraries, but that only works if
the libraries are under libraries/foo/dist-install/build/..., rather
than in inplace/lib/...

It no longer generates anything

We now also generate nice wrappers for the platformConstants
methods. For now it's all commented out as the definitions
conflict with those in Constants.

We now generate a platformConstants file that we can read at runtime.

This means we only need to build one copy of the program, which
will make life simpler as I plan to add more variants.

Patchset from Stephen Blackheath <stephen.blackheath@ipwnstudios.com>

This is working towards being able to put ghcautoconf.h and
ghcplatform.h in includes/dist

When they existed, they were getting included in the includes_H_FILES
variable (as it uses wildcard to find all header files). But the
.depends files for the programs that generate the headers depend on
$(includes_H_FILES), so the .depends files looked out-of-date once the
headers had been created. This caused unnecessary make reinvocations.

So now we put them in dist* directories, where they ought to be anyway.

We avoid calling "rm -rf" with no file arguments; this fixes cleaning
on Solaris, where that fails.

We also check for suspicious arguments: anything containing "..",
starting "/", or containing a "*" (you need to call $(wildcard ...)
yourself now if you really want globbing). This should make things
a little safer.

This patch adds support to the autoconf scripts to detect
when we are using a C compiler that uses an LLVM back end.
An LLVM back end does not support all of the extensions use
by GCC, so we need to perform some conditional compilation
in the runtime, particularly for handling thread local
storage and global register variables.

The changes here will set the CC_LLVM_BACKEND in the
autoconf scripts if we detect an llvm-based compiler. We use
this variable to define the llvm_CC_FLAVOR variable that we
can use in the runtime code to conditionally compile for
LLVM.

This isn't important, but it stops us getting [...]/./[...] in the paths
in bindists.

Note that some things depending on the rts/includes header files now
depend on more files: They used to include depend on includes/*.h, but
now they also depend on header files in subdirectories. As far as I can
see this was a bug.

They're a little nicer now, and a regression in the cygwin build is
fixed (the $i in the destination wasn't surviving being passed through
cygpath).

cygwin's /bin/install doesn't set file modes correctly if the
destination path is a C: style path:

$ /bin/install -c -m 644 foo /cygdrive/c/cygwin/home/ian/foo2
$ /bin/install -c -m 644 foo c:/cygwin/home/ian/foo3
$ ls -l foo*
-rw-r--r-- 1 ian None 0 2011-01-06 18:28 foo
-rw-r--r-- 1 ian None 0 2011-01-06 18:29 foo2
-rwxrwxrwx 1 ian None 0 2011-01-06 18:29 foo3

This causes problems for bindisttest/checkBinaries.sh which then
thinks that e.g. the userguide HTML files are binaries.

We therefore use a /cygdrive path if we are on cygwin

This way it gets the defines for the right platform when cross-compiling

Now that we are trying to support cross compilation, we can't use
    "$(TARGETPLATFORM)" != "$(HOSTPLATFORM)"
as a test for HC-porting.

We now just call gcc to get the dependencies directly

This means we can remove some conditional stuff from the Makefiles,
and means the testsuite doesn't have to work out whether or not it's
on Windows.