Add a command to list available build targets
alanz opened this issue · comments
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)
,,,
Things to bikeshed: what about a machine-readable format? Bash completion? Should we display fully qualified, or offer unqualified things?
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.
See also #3763
And it also makes sense to try and harmonise any component naming scheme with what is happening in stack
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.
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.
So you need to prefix it with the package name to disambiguate. Try hspec:spec or hspec-discover:spec.
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.
The naming scheme is [package:][component-type:]component-name. How do you want the output changed?
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.
- 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.
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.
My 5 cents:
cabal-installis 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
--convenient sounds a bit too general, how about --[no-]-flexible-matching? Otherwise +1.
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?
@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.
Four years later, are there any plans to add an analog of stack ide targets to cabal-install?
@mouse07410 repeating previous comment
No-one is working on this AFAIK, so you're welcome to.
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.
