GitLab

No idea how the last patch managed to pass validate.

I didn't realise make can invoke the same action multiple
times in parallel if the rule has multiple targets. So go
back to using a build stamp file.

Unlike with static libs, when linking shared libs the dependencies
have to already exist. Add a dependency $1_$2_$3_LIBS : $1_$2_$3_DEPS_LIBS

And depend on it at the top level when we're using dynamic libs.

when we configure ghc with --enable-shared

That is, build it as a .so/.dll rather than as libHSrts_dyn.a

For now, with --enable-shared we'll build the libs shared,
but ghc itself will still be statically linked.
In any case, we would want to be able to build it both
ways so it's easy to test both.

This allows the library file type to depend on the way. This is needed
to use .so/.dll libs for the "dyn" way rather than always using .a libs.
For example: thr_debug_dyn_libsuf="_thr_debug-ghc6.11.20090426.so"

Previously we only built library package "cbits" the vanilla way, afterall
C code does not need to be built differently for profiling builds. However
for dynamic libs the C code needs to be built with -fPIC, so we do need
to be able to build package .c (and .s?) files multiple ways.

We link stage1 using the bootstrapping compiler and there's
no guarantee that it has working support for threaded

The library uses stuff in Setup.hs to determine whether or not it needs
to use -liconv. This patch replicates that logic in ghc-cabal. This
isn't pretty, and we should find a better way to do it, but it works
for now.

Avoids a race condition, where one run deletes/overwrites the temp file
of another.

After the fix to #2500, we could get "Failing due to -Werror." but no
warnings printed. Now we don't fail in that case.

# -----------------------------------------------------------------------------
#
# (c) 2009 The University of Glasgow
#
# This file is part of the GHC build system.
#
# To understand how the build system works and how to modify it, see
#      http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture
#      http://hackage.haskell.org/trac/ghc/wiki/Building/Modifying
#
# -----------------------------------------------------------------------------

- This patch changes the equality constraint solver such that it does not
  instantiate any type variables that occur in the constraints that are to be
  solved (or in the environment).  Instead, it returns a bag of type bindings.
- If these type bindings (together with the other results of the solver) are
  discarded, solver invocation has no effect (outside the solver) and can be
  repeated (that's imported for TcSimplifyRestricted).
- For the type bindings to take effect, the caller of the solver needs to 
  execute them. 
- The solver will still instantiate type variables thet were created during 
  solving (e.g., skolem flexibles used during type flattening).

  See also http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsSolving

This showed up when converting ds057 to follow the new bang pattern rules,
in #2806.

For now we only get a warning, rather than an error, because the alex
and happy templates don't follow the new rules yet.