Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying out 7.10.3-rc1 with stack under Windows #1275

Closed
rubenmoor opened this issue Nov 3, 2015 · 8 comments
Closed

Trying out 7.10.3-rc1 with stack under Windows #1275

rubenmoor opened this issue Nov 3, 2015 · 8 comments

Comments

@rubenmoor
Copy link
Contributor

Has anyone tried out the 7.10.3 release candidate 1 with stack (cf. the announcement)?

My approach didn't get me far.
I'm working with 32-bit stack and ghc on Win7.

  • I ran stack exec which ghc to figure out where ghc currently resides.
  • I downloaded, extracted and copied 7.10.3-rc1 to ../ghc-7.10.2 to trick stack
  • I ran stack build and got weird problems with dependencies (see below).

I guess I'm doing something stupid somewhere, but can't put my finger on it.

Setting codepage to UTF-8 (65001) to ensure correct output from GHC
While constructing the BuildPlan the following exceptions were encountered:

-- Failure when adding dependencies:
free: needed (>=4 && <5), couldn't resolve its dependencies
semigroupoids: needed (>=4 && <6), couldn't resolve its dependencies
needed for package: adjunctions-4.2.1

-- Failure when adding dependencies:
base: needed (>=4.3 && <4.8.2), 4.8.2.0 found (latest is 4.8.1.0)
needed for package: base-orphans-0.4.3

-- Failure when adding dependencies:
either: needed (-any), couldn't resolve its dependencies
lens: needed (-any), couldn't resolve its dependencies
servant-server: needed (-any), couldn't resolve its dependencies
needed for package: core-0.1.0.0

-- Failure when adding dependencies:
free: needed (>=4.9 && <5), couldn't resolve its dependencies
semigroupoids: needed (>=4 && <6), couldn't resolve its dependencies
needed for package: either-4.4.1

-- Failure when adding dependencies:
semigroupoids: needed (>=4 && <6), couldn't resolve its dependencies
needed for package: free-4.12.1

-- Failure when adding dependencies:
adjunctions: needed (>=4.2 && <5), couldn't resolve its dependencies
free: needed (>=4 && <5), couldn't resolve its dependencies
semigroupoids: needed (>=4 && <6), couldn't resolve its dependencies
needed for package: kan-extensions-4.2.2

-- Failure when adding dependencies:
base-orphans: needed (>=0.3 && <1), couldn't resolve its dependencies
free: needed (>=4 && <5), couldn't resolve its dependencies
kan-extensions: needed (>=4.2.1 && <5), couldn't resolve its dependencies
semigroupoids: needed (>=5 && <6), couldn't resolve its dependencies
needed for package: lens-4.12.3

-- Failure when adding dependencies:
base-orphans: needed (>=0.3 && <1), couldn't resolve its dependencies
needed for package: semigroupoids-5.0.0.3

-- Failure when adding dependencies:
either: needed (>=4.3 && <4.5), couldn't resolve its dependencies
needed for package: servant-server-0.4.4

@rubenmoor
Copy link
Contributor Author

I deleted folders in stacks package directory (thanks @alexbiehl)

C:\Users[username]\AppData\Roaming\stack

Starting with the folder snapshots deleting other folders as well, but still end up with the error as above.

@meiersi-da
Copy link

On a related note, would it be possible to even just point the resolver to the RC-snapshot of GHC 7.10.3 and run all tests from there? That would very much improve the amount of testing that we could easily provide for a GHC release candidate.

@rubenmoor
Copy link
Contributor Author

If I am not mistaken the open issue #863 is about such functionality.

@mgsloan
Copy link
Contributor

mgsloan commented Nov 4, 2015

Actually, if you have GHC 7.10.3 installed to your PATH, stack will automatically prefer it. No tricking stack needed. See the documentation for compiler-check. The default allows for minor version bumps of GHC, and is also handy for using development versions.

There's no need to worry about 7.10.3 re-using stuff built with 7.10.2 - all the paths have the compiler version in them, so things just work.

On a related note, would it be possible to even just point the resolver to the RC-snapshot of GHC 7.10.3 and run all tests from there? That would very much improve the amount of testing that we could easily provide for a GHC release candidate.

If you want to use stack setup with the RC tarball, you can use custom setup-info in order to point stack at the RC tar gz. See the docs on the setup-info field.

@rubenmoor
Copy link
Contributor Author

Thanks @mgsloan , using set PATH=%PATH%;c\path\to\ghc-rc1\bin and stack build did the job. Now I wait for it to compile ... Hopefully the overlong command line thing is fixed and my project compiles!

@rubenmoor
Copy link
Contributor Author

Unfortunately I still encounter the problem as described above.

Putting ghc-7.10.3-rc1 on the path did not make it the first choice of stack until I also renamed the original ghc-7.10.2 folder in C:\Users\[user]\AppData\Local\Programs\stack\i386-windows

And I get the exceptions regarding missing dependencies again.

@rubenmoor rubenmoor reopened this Nov 6, 2015
@borsboom
Copy link
Contributor

I haven't been able to reproduce this on Windows with stack-0.1.8.0. Here's what I tried:

  1. Download https://downloads.haskell.org/~ghc/7.10.3-rc1/ghc-7.10.2.20151030-i386-unknown-mingw32.tar.bz2 and uncompress
  2. Add the uncompressed bin directory to the front of my PATH
  3. Run stack build in a project

It preferred the GHC on my PATH, and it rebuilt all the snapshot packages and put them in a different directory including the full version of GHC 7.10.3-rc1 (ghc-7.10.2.20151030), and everything built successfully.

My guess is that some of what you did initially to "trick" Stack has led to the stack root being in a strange state. Your best bet might be to blow it away, as well as any .stack-work directories in effected projects.

@borsboom
Copy link
Contributor

Since GHC 7.10.3 is now out, closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants