haskell_cabal_binary allow target name and executable to differ

[aherrmann]

Adds an optional attribute exe_name to haskell_cabal_binary. If set then the component exe:<exe_name> will be built, instead of the default exe:<name>. This is similar to the package_name attribute for haskell_cabal_library.

Converts tests/haskell_cabal_package into a test-case for this feature, tests/haskell_cabal_binary serves as a test-case that doesn't use exe_name.

The motivation for this is to lay the ground to enable stack_snapshot to build executable components as well as library components. E.g. in a case like ghcide where the target name ghcide is already taken by the library component, the executable component cannot be called ghcide as well.

[mboes]

@aherrmann is there precedent for exe in Bazel rules? We usually favour Bazel precedent over Cabal precedent when in conflict.

[mboes]

Come to think of it, having an exe_name field is unusual. Because we now can't count on the name of the target being the name of the binary, when that is always the case elsewhere. We could go the other way: have a package_name field in haskell_cabal_binary just like in haskell_cabal_library, that gives the name of the package, and then use the name of the binary as the target argument that we provide to Cabal, which would be of the form exe:<name>.

[aherrmann]

@mboes The problem is collision between library and executable components. Take the doctest package, it has a library component and an executable component also called doctest. If we want to generate library and executable targets for it in stack_snapshot down the line, how should we call each?

The approach I'm suggesting so far would be

haskell_cabal_library(name = "doctest", ...)
haskell_cabal_binary(name = "doctest_exe_doctest", exe_name = "doctest", ...)

If we want to call the binary doctest, then we'd have to call the library something else.

[mboes]

Arguably binaries should go in a separate namespace, because their names could clash with a library name. I'd have,

@stackage//:doctest
@stackage-bin//:doctest

Which is easier to remember than any mangling of the binary name. Now, you could ask, what happens if two packages export a binary with the same name? That's a situation Cabal doesn't handle well, but we can do better. For some reason that I don't remember, we chose to have @stackage//:doctest instead of @stackage//doctest:doctest (I think this was discussed in the original ticket). However, if we switched to the latter, then we'd have a reasonable scheme for both binaries and packages that export multiple libraries (which Cabal now allows). We'd have e.g.

@stackage//doctest:doctest
@stackage//doctest/exe:doctest

Doesn't look so nice. But how about,

@stackage//doctest:doctest
@stackage//doctest:another-public-library
@stackage-bin//doctest:doctest

Is there an issue associated to this feature, where we could continue the design discussion?

[aherrmann]

Is there an issue associated to this feature, where we could continue the design discussion?

I've created #1306 to continue the discussion.

[guibou]

I'm fine with this. However @mboes suggested an interesting discussion.

[aherrmann]

As discussed in #1306 this is required for executable support in stack_snapshot for technical reasons. However, for the user facing executable targets we can use aliases to hide the name mangling.

[aherrmann]

@Mergifyio rebase

[mergify]

Command rebase: success

Branch has been successfully rebased