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 install --compiler-specific #2643

Closed
mgsloan opened this Issue Sep 27, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@mgsloan
Collaborator

mgsloan commented Sep 27, 2016

I am splitting this issue off from #1796, because the discussion there got long and so potentially also intimidating. I think this is a very important feature that will be great for intero and similar tools. The idea is simple:

stack install --compiler-specific will be a magical incantation that installs tools directly to the compiler bin directory. It is easy to implement, and an important enhancement, so I am marking this P1.

For global installs of GHC, it should warn that it might not have the intended semantics. Like if ghc is in /usr/local/bin, we may well be overwriting intero compiled against a different ghc, and that might not be expected.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Oct 20, 2016

I think it would be good to implement this before the next release. My current thoughts on this feature are:

  1. Have stack path --compiler-tool-bin, yielding a path to the dir compiler-specific tools are installed to
  2. Have stack build --copy-compiler-tool, which causes executables for target packages to get copied to the compiler-specific dir.
  3. Have this compiler-specific dir always included on the PATH.

At first I thought it would make sense to put these within the programs directory tree. For example, $STACK_ROOT/programs/x86_64-linux/ghc-7.10.3/bin would be alongside $STACK_ROOT/programs/x86_64-linux/ghc-7.10.3/stack-tools-bin.

However, this doesn't properly handle the case of having a tool associated with a globally installed ghc. A few options come to mind:

  1. Simply disallow using this feature with a global install of GHC

  2. Have the tools folder be located in the ghc bin dir, possibly under the name bin/stack-tools/.

  3. Default, and warn about it, and just do the install to the normal location when used with the global GHC (~/.local/bin)

I'm leaning towards doing the 3rd option. What do folks think?

@Blaisorblade

This comment has been minimized.

Collaborator

Blaisorblade commented Oct 20, 2016

Caveat: I have only read this issue, so might miss info from #1796.

  • Option 3 (of the 2nd list) would currently break at least intero if the global install coexists with stack-managed installs: the intero Emacs mode doesn't install the intero binary if there's one on the PATH. I once installed intero in ~/.local/bin and was told that's an invalid configuration. If intero was enhanced to use this feature, it'd have to either show the warning to the user, or simply pay attention to never use it.

In other words: compiler-specific tools can't be accessible on the default PATH. Failing that, they shouldn't be accessible via stack exec for other compilers.
stack exec --package intero intero wouldn't take advantage of this option, unless we also support --compiler-specific for stack exec.

  • Viceversa, with option 1, intero could just fall back to its current handling, and the same for stack users who install tools by hand (I do that with intero out of precaution, and I suppose that might be needed for some other tools).
  • Option 2 might be even better, as long as the bin/stack-tools folder is inside $STACK_ROOT (and versioned by GHC version) to avoid having to write to a possibly-readonly global installation.
@Blaisorblade

This comment has been minimized.

Collaborator

Blaisorblade commented Oct 20, 2016

Also, pinging @chrisdone regarding intero needs.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Oct 21, 2016

unless we also support --compiler-specific for stack exec.

These tools would always be available on the PATH when used with a configuration that includes that particular compiler. I'm not thinking very hard about the specifics of intero, because this is a very general feature.

Option 2 might be even better, as long as the bin/stack-tools folder is inside $STACK_ROOT (and versioned by GHC version) to avoid having to write to a possibly-readonly global installation.

Yeah, it may be reasonable to have a whole new directory structure for this stuff. like $STACK_ROOT/compiler-specific-tools/$ARCH/$COMPILER/bin orso

mgsloan added a commit that referenced this issue Nov 28, 2016

@mgsloan mgsloan referenced this issue Nov 28, 2016

Merged

Implementation of "--copy-compiler-tool" #2643 #2812

2 of 2 tasks complete

@mgsloan mgsloan modified the milestones: P2: Should, P1: Must Nov 28, 2016

mgsloan added a commit that referenced this issue Nov 28, 2016

@kadoban

This comment has been minimized.

Collaborator

kadoban commented Aug 11, 2017

Is this blocked by anything in particular? I ask because I'd be willing to help if I'm able, if there's tasks that need to be done. I see the PR and it seemed to work based on a very minimal test.

I really like this idea, the lack of something-like-this is a lot of why I stopped bothering with fancy things like ghc-mod way back when I switched to stack, and it seems like such a nice clean way to fix.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Aug 11, 2017

@kadoban I wasn't 100% certain it'd solve things nicely for intero, see commercialhaskell/intero#324 . Looking back at it, this seems like a pretty good step in the direction of improving how intero works, and would be helpful for other tools.

So I think this just needs to be rebased. Probably lots of conflicts. If you're up to it, would be appreciated!

@kadoban

This comment has been minimized.

Collaborator

kadoban commented Aug 12, 2017

@mgsloan sure, I'll certainly give it a try, should be able to manage.

Edit: working on it done, comment/progress in #2812

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Sep 17, 2017

Got merged, so closing

@mgsloan mgsloan closed this Sep 17, 2017

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