GitLab

setupRtsFlags(): don't overwrite argv[0] with its basename:
   - argv[] may not point to writeable memory
   - System.Environment.getProgName strips off the 'dirname' portion
     anyway.
   - Not possible to get at the untransformed argv[0] from
     Haskell code, should such a need arise.

Uses of prog_argv[0] within the RTS has now been replaced with prog_name,
which is the basename of prog_argv[0].

mkHomeModLocation: basename has to be equal to module name, not just suffix

The autoconf magic for the library documentation belongs to
libraries/, not ghc/.

OpenBSD's sh doesn't like the parentheses in "foo='(-1)'" so let's
drop them. Thanks to Don for pointing this out.

Added a new test FP_HTML_COMMENT (better name?) and use it in configure.ac.

As an additional bonus, autoreconf doesn't call aclocal anymore
because we have an aclocal.m4 now and it obviously doesn't require
automake stuff. This fixes problems with older (< 1.4-p6) automakes,
which insist on "configure.in".

Oops. Should import Directory instead of System.Directory.

my_prefix_match ~> Util.maybePrefixMatch

Nuked FPTOOLS_O_BINARY test and use FP_CHECK_CONST instead, which is
shorter and better (e.g. cross compilation).

* Cleaned up FP_CHECK_ALIGNMENT test a bit.

* Nuked FPTOOLS_CHECK_CCONST test in favour of a more general one
  which handles cross compilation and languages different from C.

pprInstr{PPC}: insist on xori,ori,andi being fed non-negative immediate values.
               GAS is barfing on neg. values.

[ Don't have access to a PPC box right now to really test the change, so beware.]

After removing temp files, reset the list of temporary files to empty.

Don't drop {-# LINE #-} pragmas into the source, because it confuses
CPP's line counts, making them off-by-one.  GHC understands the
CPP-style line pragmas anyhow.

Use Util.maybePrefixMatch instead of DriverUtil.my_prefix_match, and
remove the latter.

Define maybePrefixMatch, which is like prefixMatch but returns the
rest of the String after the match.

Fix bug in hashSubStringBA, which it appears has been broken for
ever.  However, I suspect so far we've never tickled the bug in GHC.

Nuked the broken FPTOOLS_CC_FLAG test and added a more general
FP_CHECK_FLAG test instead.

External Core programs sometimes contain newtype declarations with no
data constructors. GHC expected every newtype declaration to have at
least one data constructor, so it would previously fail with an "empty list"
error if you tried to compile such a program. These declarations are handled
properly now.

Added correct parsing of external calls. External calls are assumed to be
static C calls, but this assumption should always hold since compiling to
External Core will fail for programs that contain any other kind of
external call.

Added correct parsing of the null-pointer literal (0::GHCziPrim.Addrzh) --
this caused an "unknown integer literal type" error before.

Changed outputForeignStubs to check whether stub files from a previous
compilation still exist (in the case where no new stubs exist). This is
necessary to compile External Core programs that require these stubs.

Two issues:

1. According to the spec for External Core, datatype declarations are required
to have at least one data constructor. Previously, if you tried to generate
External Core for a program containing a datatype declaration with no
constructors, generating the Core file would succeed, but compiling it would
result in a parse error. Changed MkExternalCore to signal an error if such
a declaration is encountered while compiling to External Core.

2. Previously, MachLabel literals were translated into Externals when compiling
to External Core. This is wrong -- such literals are not foreign calls and
can't be handled in the same way (compiling any External Core code generated
from code containing literals resulting from "foreign label" declarations would
result in a strange error message). There doesn't seem to be any way to
correctly represent these labels in External Core, so MkExternalCore now
signals an error if one of these is encountered as well.

setlocale(LC_ALL,""), to enable the locale support in libc.

Check for locale.h and wctype.h

Nuked FPTOOLS_MSGHDR_MSG_ACCRIGHTS and FPTOOLS_MSGHDR_MSG_CONTROL
tests. Use autoconf's own macros for dealing with struct members.

Death to the acconfig.h hack!

Well, we really need autoconf 2.52...

Expand the (a bit faulty) definition of AC_MSG_FAILURE, which is only
available since autoconf 2.57. Thanks to Don for pointing this out.

To ease autoheader's job, add description for USE_QUARTZ_OPENGL.

Renamed FP_ALTZONE to FP_DECL_ALTZONE

Revamped FPTOOLS_PROG_DIFF

Nuked AC_C_PROTOTYPES macro. We don't need the result and newer
autoconfs come with their own definition.

Nuked unused macro FPTOOLS_IN_SCOPE

* Revamped macro for alignment test
* Fixed a few tests for "long long"s

Nuked FPTOOLS_C_LONG_LONG, AC_CHECK_TYPES already does what we want.

Don't build ltx and sgmlverb, they are unused. With this change, the
test for flex/lex can be removed from the configuration process. The
make rules for flex/lex files are still in mk, but they could be moved
to glafp-utils/mk if someone feels the need for this.

Nuked ancient "msub" stuff and a CVS keyword on the way.

Ooops, forgot about a dozen references to configure.in... :-}

AC_PROG_LEX really checks for the existence of "lex" when "flex" is
not found, so there is no need for AC_PROG_LEX_STRICT.

Furthermore, flex/lex is not really needed for building GHC, so we
issue only a warning instead of dying when flex and lex are not found.

Nuked unused FPTOOLS_PROG_YACCY test and support for yacc/bison in
general. If it is ever needed again, it can easily be resurrected.

Nuked unused FPTOOLS_REGEX_IN_LIBC test

Revamped altzone detection. Note that we test only for successful
compilation now, not for successful linking, but this is what most
autoconf macros do.

* Following the autoconf coding style recommendations, use "#" for
  comments, not "dnl".

* Local macros will get the prefix "FP_" instead of "FPTOOLS_". The
  latter is a bit heavyweight and too fptools-centric.