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

Add a command to list available build targets #4070

Open
alanz opened this Issue Nov 1, 2016 · 16 comments

Comments

Projects
None yet
5 participants
@alanz
Collaborator

alanz commented Nov 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Nov 1, 2016

Contributor

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

Contributor

ezyang commented Nov 1, 2016

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

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 1, 2016

Collaborator

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.

Collaborator

alanz commented Nov 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 2, 2016

Collaborator

See also #3763

Collaborator

alanz commented Nov 2, 2016

See also #3763

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 2, 2016

Collaborator

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

Collaborator

alanz commented Nov 2, 2016

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

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Nov 3, 2016

Member
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.

Member

23Skidoo commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 3, 2016

Collaborator
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.

Collaborator

alanz commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Nov 3, 2016

Member

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

Member

23Skidoo commented Nov 3, 2016

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

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 3, 2016

Collaborator

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.

Collaborator

alanz commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Nov 3, 2016

Member

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

Member

23Skidoo commented Nov 3, 2016

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

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 3, 2016

Collaborator

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.

Collaborator

alanz commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Nov 3, 2016

Member

- 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.

Member

23Skidoo commented Nov 3, 2016

- 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

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Nov 3, 2016

Collaborator

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.

Collaborator

alanz commented Nov 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@phadej

phadej Nov 4, 2016

Collaborator

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

Collaborator

phadej commented Nov 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Nov 4, 2016

Member

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

Member

23Skidoo commented Nov 4, 2016

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

@IvanMalison

This comment has been minimized.

Show comment
Hide comment
@IvanMalison

IvanMalison Oct 26, 2017

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 commented Oct 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Oct 26, 2017

Member

@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.

Member

23Skidoo commented Oct 26, 2017

@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.

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