Add a command to list available build targets

[alanz]

Given that cabal.project can list additional local components, each with its own cabal file, it is not always clear what the appropriate build targets are.

So perhaps add a command that will list the targets, e.g.

cabal list-targets

component Cabal
  cabal  (lib)
  cabal:unit-tests (test-suite)
  cabal:parser-tests (test-suite)
  cabal:parser-hackage-tests (test-suite)
  ...
component cabal-install
  cabal-install:cabal (exe)
  cabal-install:unit-tests (test-suite)
 ,,,

[ezyang]

Things to bikeshed: what about a machine-readable format? Bash completion? Should we display fully qualified, or offer unqualified things?

[alanz]

Related to this

If I configure my project, I get something like

In order, the following will be built (use -v for more details):
 - HaRe-0.8.3.0 (lib) (first run)
 - HaRe-0.8.3.0 (test:spec) (first run)
 - HaRe-0.8.3.0 (exe:ghc-hare) (first run)

But, to build each of these, I need to do

cabal new-build HaRe
cabal new-build spec
cabal new-build ghc-hare

It would be more useful if the naming was consistent, between the reported target names and how to request a build of the specific target.

[alanz]

See also #3763

[alanz]

And it also makes sense to try and harmonise any component naming scheme with what is happening in stack

[23Skidoo]

cabal new-build spec
cabal new-build ghc-hare

cabal new-build test:spec exe:ghc-hare will also work. Instead of (lib) we should probably output (lib:HaRe), since new-build lib doesn't work and we now support internal libs.

[alanz]

cabal new-build test:spec
Resolving dependencies...
cabal: Ambiguous build target 'test:spec'. It could be:
hspec-discover:spec (component)
spec (component)

cabal new-build exe:ghc-hare works as expected.

[23Skidoo]

So you need to prefix it with the package name to disambiguate. Try hspec:spec or hspec-discover:spec.

[alanz]

Well, given that the HaRe package has a test target called spec, I would expect that to be chosen unless there is a specific prefix.

This issue is about having a naming scheme for targets, both for reporting in build output and invoking as a command.

[23Skidoo]

The naming scheme is [package:][component-type:]component-name. How do you want the output changed?

[alanz]

Changing it to

In order, the following will be built (use -v for more details):
 - HaRe-0.8.3.0 (lib:HaRe) (first run)
 - HaRe-0.8.3.0 (spec) (first run)
 - HaRe-0.8.3.0 (exe:ghc-hare) (first run)

Would make it consistent with the command to build the component, which is what I am after.

[23Skidoo]

- HaRe-0.8.3.0 (spec) (first run)

IMO, it should stay as test:spec. The reason it fails for you is because you have multiple packages in your project with a spec component.

[alanz]

Well, this is just one example, and I am sure there will be many similar projects.

To me it is a problem that there is not a concept of a default package, being the one in the current directory, being worked on, vs any of the dependencies. If no prefix is given, it should assume the current package.

[phadej]

My 5 cents:

• cabal-install is used by both, machines and humans.
• There are situations where I want machine yell at me "I don't want you to guess", where sometimes I especially use machine so it will make good guesses for me.

My proposal, introduce config value + flag pair "--convenient" and "--non-convenient". So interactive users with convenience enabled would get cabal do something, if only cabal new-build spec can be interpreted in reasonable way. With convenience disabled, cabal new-build spec would even refuse do do anything, even it's obvious, but require cabal new-build HaRe:test:spec to be spelled out.

Another way to think about this is plumbing/porcelain separation in git. Separate commands for human and machines (where former use latters, obviously).

Another such separation is whether or not try to guess case-insensitively the package name.

Check e.g. git status and git status --porcelain

[23Skidoo]

--convenient sounds a bit too general, how about --[no-]-flexible-matching? Otherwise +1.

[colonelpanic8]

Doesn't seem like any forward progress has been made on this in a while. I take it there are no plans to move forward on this in any way?

[23Skidoo]

@IvanMalison No-one is working on this AFAIK, so you're welcome to. But please post a short summary of what you're planning to do here so that we could comment.

[mouse07410]

Four years later, are there any plans to add an analog of stack ide targets to cabal-install?

[phadej]

@mouse07410 repeating previous comment

No-one is working on this AFAIK, so you're welcome to.

[mouse07410]

No-one is working on this AFAIK, so you're welcome to.

If I had greater proficiency in Haskell, that's exactly what I would've done.

As it is, unfortunately, I have to (regretfully) resort to asking those with more expertise in this.

[gbaz]

Should be resolved by #7500