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

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

Closed
mwu-tow opened this Issue Sep 25, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@mwu-tow
Contributor

mwu-tow commented Sep 25, 2015

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 added a commit that referenced this issue Sep 27, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 27, 2015

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.

@snoyberg snoyberg added this to the P1: Must milestone Sep 27, 2015

@snoyberg snoyberg self-assigned this Sep 27, 2015

@mwu-tow

This comment has been minimized.

Contributor

mwu-tow commented Sep 27, 2015

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! :-)

@mwu-tow mwu-tow closed this Sep 27, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 27, 2015

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).

mgsloan added a commit that referenced this issue Oct 7, 2015

@mwu-tow

This comment has been minimized.

Contributor

mwu-tow commented Oct 19, 2015

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?

@mwu-tow mwu-tow reopened this Oct 19, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Oct 19, 2015

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

This comment has been minimized.

Contributor

mwu-tow commented Oct 20, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Oct 21, 2015

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

This comment has been minimized.

Contributor

mwu-tow commented Oct 21, 2015

I can give it my try.

mwu-tow added a commit to mwu-tow/stack that referenced this issue Oct 21, 2015

snoyberg added a commit that referenced this issue Oct 22, 2015

Merge pull request #1210 from mwu-tow/master
Ignoring stack-built `ghc` executables when looking for compiler for Setup.hs (#1052).
@mwu-tow

This comment has been minimized.

Contributor

mwu-tow commented Oct 22, 2015

I'm closing this issue, it is fixed by #1210 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment