Generate 'stack' tool style compilation targets.

[csasarak]

This is an initial attempt at addressing issue #1187. Please let me know if there's a better way, this is my first outing into the haskell-mode code.

[gracjan]

Looks good to me. If nobody raises any voices agaist I'll merge this in a day or two.

[hvr]

What are "stack tool style" compilation targets exactly btw? Is this any different from cabal's compilation target syntax? For reference (as I couldn't find a place where this is documented), Cabal uses the following (fully-qualified) syntax to identify components within a project containing one or more packages:

<packagename>:<component-type>:<component-name>

where <component-type> := {exe,lib,bench,test}

When it's unambiguous, it's allowed to use less qualified forms, e.g.

• mypackage:exe:myprog1, exe:myprog1 or myprog1
• mypackage
• mypackage:lib or mypackage:lib:mypackage (this denotes the primary library of a package - cabal 2.0 supports multiple libraries per package)

[hvr]

what is a projectName? Does Stack name projects?

[csasarak]

projectName is whatever appears in the 'name:' field at the top of the cabal file, it's in one of the hidden sections in the diff, but projectName is defined on line 481 with (haskell-cabal--get-field "name"). Stack doesn't have a separate notion of a project to what cabal provides as far as I can tell.

[hvr]

oh I see, then clearly projectName is a misnomer (but your PR didn't introduce it... it was already in the codebase before that... :-) )

[csasarak]

I can switch it to package-name which might be more appropriate while I'm making edits tonight.

[csasarak]

I hadn't realized that cabal also uses that syntax since as you said it isn't documented anywhere. Stack uses a very similar syntax, but it's required: https://docs.haskellstack.org/en/stable/build_command/#target-syntax
The issue I was having that I would try to switch to a test-suite which had different dependencies than the library package. Using haskell-session-change-target and then building would fail because it would try to use a target like 'project-test' when stack requires 'project:project-test', or possibly ':project-test'.

[gracjan]

Is cabal syntax same as stack syntax?

If so we should just be using fully qualified target specs for all cases. This is autocompletion after all, so it makes sense to list fully qualified target names.

@hvr: good catch, I did not know cabal has extended syntax. Since when is it supported?

[csasarak]

@gracjan Comparing the description and Stack's documentation, the one case where it seems to be different is that Stack allows something like :project-test as a target but it doesn't seem that cabal does per @hvr's comment. If cabal is okay with that though, it would be simpler to just always do the extended syntax.

[gracjan]

We should do fully qualified syntax always. @csasarak: can you fix that? Thanks.

[csasarak]

@gracjan I will try to take care of that tonight.

[hvr]

@gracjan I think the 3-part syntax is only supported in new-build; whereas the 2-part {lib,bench,test,exe}:<name> syntax was already supported by older cabal versions; but I'm not sure how far back.

[csasarak]

@hvr Is it okay then to assume that current cabal users will use new-build? So I can unconditionally generate the 3-value target? The 2-value syntax used by stack is <package-name>:<name> but the syntax you describe is <component-type>:<name>.

[ivan-m]

@csasarak: I'm not using new-build yet (I looked at it earlier this year but it didn't seem to have all the functionality yet, at least not documented well enough for me to work out how to use it)

[csasarak]

@ivan-m Good to know, I'm playing with stack and cabal tonight (I'm most familiar with stack) so I can take a more educated stab at this.

[csasarak]

So unfortunately the acceptable syntax for targets are different between stack and cabal.
stack build package:package-test works but cabal build package:package-test does not while cabal build test:package-test works but stack build test:package-test does not. Unfortunately the fully qualified names that stack accepts (like stack build package:exe:package-exe) aren't accepted by cabal unless you do cabal new-build.

I have a solution that I want to test a bit more, but if we anticipate stack command syntax deviating from cabal more in the future (or vice versa) it would probably make more sense to forgo my solution and have some abstraction so that stack command and cabal command strings aren't being generated in the same place.

[hvr]

@csasarak I think it's reasonable to assume that Stack won't coordinate their syntax w/ Cabal upstream. So anticipating syntax deviation and abstracting seems reasonable.

[ivan-m]

Ebal has a very nice interface for this.

[csasarak]

@ivan-m Ebal does look promising.
@hvr Okay, it'll take me some time to get more acquainted with how things are done. Unless it makes more sense to write tests for what I have already and then refactor the commands as a separate task/issue?

[gracjan]

For uninitiated: https://github.com/mrkkrp/ebal

[gracjan]

In this case we should split code paths inside haskell-mode for ghci, cabal and stack properly. This is a more involved change, but needed very much. Would be great to have a more principled approach to the issue.

[csasarak]

I've added some tests to my original implementation for the stack/cabal fully-qualified targets. I'd need some time to look at the code in order to make a decent decision about how to split things up and will be traveling for the next week and a half or so, so I won't make any progress during that time. Still, if you have any advice for where to start (haskell-interactive-mode.el?) I can look into it when I return.

[gracjan]

We can merge it for now and refactor later. Is it ready to be merged in current state?

[csasarak]

To the best of my knowledge it's ready to be merged.