stack prefers ghc from .stack-work\install\…\bin over the one from PATH

[mwu-tow]

I have a package that compiles to the executable named ghc.exe.
When building first time, everything works fine. The install step places the built ghc.exe in the .stack-work\install\x86_64-windows\lts-2.22\7.8.4\bin directory. As expected.

However, any subsequent stack build command will fail:

    setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.8.4.exe: The program 'ghc' version >=6.4 is required but the version of C:\z\.stack-work\install\x86_64-windows\lts-2.22\7.8.4\bin\ghc.exe could not be determined.
    setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.8.4.exe: fd:5: hGetContents: invalid argument (invalid byte sequence)

To built it again I have to delete .stack-work directory.

It is because stack tried to use .stack-work\install\x86_64-windows\lts-2.22\7.8.4\bin\ghc.exe — that is not an actual GHC but the locally built package that was just named so.

I expect that stack should prefer ghc.exe from PATH or its ghc-paths over the built executables. The results of build should not affect subsequent builds, and overwriting the compiler executable should not be implicit.

[snoyberg]

I've pushed a patch to master to pass in --with-ghc to the configure step, which should fix this. Can you give it a shot?

In general with build tools, however, we want to use them for building things (e.g., a Stack-built alex should be used instead of whatever's on the PATH). I'm OK special-casing this for GHC, but in general having an executable shadow the name of another build tool should be considered an error.

[mwu-tow]

Actually I'm a little surprised that stack-built build tools should be preferred over the PATH. I'd expect that stack build simply builds things and should not affect how subsequent stack build. Doesn't it weaken the rule of reproducible builds? If I wanted, I'd try using something like stack exec stack build (does this makes sense?) or just install the build tools.
[Not saying you should change how things work, just thought it might be worth of noting.]

Is there any way I can prevent build artifacts from affecting the build?

Anyway, with the latest master everything works fine for me. Many thanks! :-)

[snoyberg]

Consider the case of a tool like alex. Stack needs to build it in order for
other packages to use it, and we want to prefer that version of alex to
whatever happens to be on the PATH

On Sun, Sep 27, 2015, 10:41 AM Michał Wawrzyniec Urbańczyk <
notifications@github.com> wrote:

Closed #1052 #1052.

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

[mwu-tow]

This fix seems to be broken in 0.1.6.0 release. Once again the compiled ghc gets used instead of the original one.

It works fine if I use your commit 0548ee2 but when I upgrade to release version it is broken again. Should I try checking when exactly it got broken?

[snoyberg]

That would be great.

On Mon, Oct 19, 2015 at 8:00 PM, Michał Wawrzyniec Urbańczyk <
notifications@github.com> wrote:

This fix seems to be broken in 0.1.6.0 release. Once again the compiled
ghc gets used instead of the original one.

It works fine if I use your commit 0548ee2
0548ee2
but when I upgrade to release version it is broken again. Should I try
checking when exactly it got broken?

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

[mwu-tow]

Done some bisecting, apparently the regression comes from 747cd0f .
Could it be that GHC used to compile Setup.hs is taken from the build?

[snoyberg]

Would you be interested in trying your hand at a PR based on the previous
fix for this?

On Tue, Oct 20, 2015, 4:37 PM Michał Wawrzyniec Urbańczyk <
notifications@github.com> wrote:

Done some bisecting, apparently the regression comes from 747cd0f
747cd0f
.
Could it be that GHC used to compile Setup.hs is taken from the build?

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

[mwu-tow]

I can give it my try.