Feature request : recognise current development ghc

[alanz]

If I use a private build of the ghc-7.10 GHC branch as the system compile, stackage creates an artifact cache as

$HOME/.stack/snapshots/x86_64-linux/nightly-2015-06-25/7.10.1.20150619

If I use a private build of GHC master, stackage does not recognize it as a separate compiler and reuses one of the other caches, causing problems

ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.11.20150621

stack --version
Version 0.1.0.0, Git revision 2b2f95c6fc1f12111439b70a376267f6ce28f597

I am switching compiler versions via https://github.com/spl/multi-ghc

[snoyberg]

Sorry, I'm having trouble understanding the report. What's the difference between the "private build" and the "build of GHC master"? Where are the artifacts of the GHC master build going?

[alanz]

They are both private builds, i.e. built and installed locally as the
system compiler.

If I set ghc 7.10.1.20150619 as the current system compiler, after rm -fr ./stack-work and stack build, I end up with

.stack-work/install/x86_64-linux/nightly-2015-06-25/7.10.1.20150619

If I set ghc 7.11.20150621 as the current system compiler, after rm -fr ./stack-work and stack build, I end up with

.stack-work/install/x86_64-linux/nightly-2015-06-25/7.10.1

I would expect to see

.stack-work/install/x86_64-linux/nightly-2015-06-25/7.11.20150621

On Fri, Jun 26, 2015 at 10:18 AM, Michael Snoyman notifications@github.com
wrote:

Sorry, I'm having trouble understanding the report. What's the difference
between the "private build" and the "build of GHC master"? Where are the
artifacts of the GHC master build going?

—
Reply to this email directly or view it on GitHub
#423 (comment)
.

[snoyberg]

My guess is that it's using the stack-installed GHC 7.10.1 instead of your patched version, likely because your stack.yaml has a resolver that requires GHC 7.10. Setting it to resolver: 7.11 or using --resolver ghc-7.11 should fix it.

My guess is that your next request will be a command line flag to disable checking that the GHC version actually matches, since you want to test the Stackage NIghtly build plan with HEAD. Is my precognition working today? ;)

[alanz]

That does sound like it would do the trick :).

On a related note, how simple is it to install a locally built compiler
into the $HOME/.stack/programs directory? And then request it in a
stack.yaml, now that we have --stack-yaml.

This is quite an esoteric use case, so I expect it to be very low priority.

On Fri, Jun 26, 2015 at 10:32 AM, Michael Snoyman notifications@github.com
wrote:

My guess is that it's using the stack-installed GHC 7.10.1 instead of your
patched version, likely because your stack.yaml has a resolver that
requires GHC 7.10. Setting it to resolver: 7.11 or using --resolver
ghc-7.11 should fix it.

My guess is that your next request will be a command line flag to disable
checking that the GHC version actually matches, since you want to test the
Stackage NIghtly build plan with HEAD. Is my precognition working today? ;)

—
Reply to this email directly or view it on GitHub
#423 (comment)
.

[snoyberg]

Alright, it's on master. Can you give it a shot?

[alanz]

Just tested it, it works as advertised. Thanks.

I just need to tweak some dependencies, will push my example a bit later.

[alanz]

See https://github.com/alanz/ghc-exactprint/tree/wip#building-with-stack for a working example