Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

I noticed this bug when porting a (dead code) test case
for new-build on executables to the new test suite; I
noticed that if you do a fresh new-build on a project
with lib and executable, specifying to only build the
executable, AND the executable doesn't depend on the lib,
new-build incorrectly decides to try to register the lib
even though no lib was actually built.

This is because "needs registration" was computed pre-pruning.
I turned elabNeedsRegistration into a function that looks
at the post-pruning elabBuildTargets to determine if we
are actually going to build a library or not.

This was actually a bit tricky (I introduced a regression)
with regards to handling when there are NO targets.  We have
a regression test for this now.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Tips for CI. [skip ci]

Clean up PreExistingComponent

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This code doesn't matter to much, but might as well fix it while we change
it.

This makes clear that we aren't accidentally relying on other infos to be
likewise patched for correctness --- otherwise a big potential bug

It no longer hacks around build-depends: that code has been moved to
Backpack.Configure, and will be removed altogether with LibDependency

Switch GHC 8.0 series to 8.0.2 in CI.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fix accidentally broken call stacks.

finalizedPD: Simplify with Either monad

This can occur if we catch an exception (which had markers)
and then embed the error string into another error string.
If the test runner picks up the nested marker that's disaster.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

- Now if a rewriteFile fails, we'll get a stack trace on -v.
  We should rewrite writeFileAtomic but it's in the wrong
  module and it would involve changing a lot of clients, so
  this is a more conservative change.

- We no longer wrap error messages in top handler, so that
  the stacks look better.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Break up Distribution.Package -- only classes and reexports remain

Don't specify hs-libraries when none exists!

This fixes GHC bug
https://ghc.haskell.org/trac/ghc/ticket/13268



Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago

The strategy is to save an 01-index.timestamp file that remembers
what --index-state the user requested during cabal update.
Subsequently, we use that index state if no more precise
index state was specified (via the flag or a project config.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>