Skip to content
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

"stack build" succeeds, but "stack build --only-configure" fails #920

Closed
luigy opened this issue Sep 4, 2015 · 13 comments
Closed

"stack build" succeeds, but "stack build --only-configure" fails #920

luigy opened this issue Sep 4, 2015 · 13 comments
Milestone

Comments

@luigy
Copy link
Contributor

@luigy luigy commented Sep 4, 2015

> stack build
servant-0.5: build
servant-0.5: install
servant-client-0.5: configure
servant-client-0.5: build
servant-server-0.5: configure
servant-server-0.5: build
servant-client-0.5: install
i-fail-when-only-configure-0.1.0.0: configure
i-fail-when-only-configure-0.1.0.0: build
i-fail-when-only-configure-0.1.0.0: install
servant-server-0.5: install
servant-server-0.5: install
Completed all 4 actions.
> stack build --only-configure
Progress: 3/4singleBuild: invariant violated, missing package ID missing

singleBuild: invariant violated, missing package ID missing

the missing package ID is servant-0.5
(maybe stack should probably show the package ID instead of just "missing" as well?)

# stack.yaml

flags: {}
packages:
- '.'
- location:
    git: https://github.com/aaronlevin/servant.git
    commit: 48a5d1474aab40ad1fe79353a23f8abc428be90c
  subdirs:
    - servant
    - servant-client
    - servant-server
extra-deps: []
resolver: lts-3.3
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Sep 4, 2015

That's actually the documented behavior:

  --only-configure         Only perform the configure step, not any builds.
                           Intended for tool usage, may break when used on
                           multiple packages at once!

Usage of the --only-configure is intended exclusively for tools that rely on some internal Cabal files, and should not be used by most people. See #820 for the discussion. What's the use case that you're using it?

Loading

@luigy
Copy link
Contributor Author

@luigy luigy commented Sep 4, 2015

hmm, I see... It was actually using ghc-mod that I ran into this
to get the expected behavior currently I have to be explicit:

stack build servant-0.5
stack build servant-client-0.5
stack build servant-server-0.5
stack build --only-configure

pinging @DanielG for some feedback

I feel like I should close this issue and open one in ghc-mod instead?

Loading

@DanielG
Copy link
Contributor

@DanielG DanielG commented Sep 4, 2015

We always call stack build --only-dependencies before calling --only-configure so it's-not-my-fault^TM ;)

See: https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/CabalHelper.hs#L240

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Sep 6, 2015

As mentioned in the original issue, and in the stack build --help output, this is not the way the feature is designed to work, you need to give it just a single target package for reliable results. Taking the wai project as an example, stack build --only-dependencies would not build wai (since it's a target, not a dependency) whereas stack build --only-dependencies warp would build wai (since it's no longer a dependency). stack has no way of knowing which package you're trying to get it to build.

Perhaps the call should be stack build --only-dependencies . && stack build --only-configure . to just build things in the current directory?

Loading

@snoyberg snoyberg added this to the Support milestone Sep 6, 2015
@DanielG
Copy link
Contributor

@DanielG DanielG commented Sep 7, 2015

We don't support multi-package stack projects yet though (going to add that now). We only apply this stuff when the stack file is next to the cabal file, so in the case where there are multiple packages this shouldn't even run. Are the commands in that case equivalent to the ones without "." at the end or is there a difference?

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Sep 7, 2015

@luigy Can you share you project's stack.yaml file?

@DanielG it all depends on the directory hierarchy.

Loading

@luigy
Copy link
Contributor Author

@luigy luigy commented Sep 7, 2015

using stack @ 7153be8 project was just scaffolded using stack new i-fail-when-only-configure and slightly modified here stack.yaml and i-fail-when-only-configure.cabal

@snoyberg I find this unregistering odd. Is it expected? something about local vs snapshot dbs?
I would expect noop but, even when I stack build . && stack build . --only-configure it also triggers the unregistering

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Sep 7, 2015

Can you set extra-dep: true on your Git package?

Loading

@luigy
Copy link
Contributor Author

@luigy luigy commented Sep 7, 2015

Almost, now I get this also with just stack build

stack build servant-server-0.5 does install greet successfully, though

flags: {}
packages:
- '.'
- location:
    git: https://github.com/aaronlevin/servant.git
    commit: 48a5d1474aab40ad1fe79353a23f8abc428be90c
  subdirs:
    - servant
    - servant-server
    - servant-client
  extra-dep: true
extra-deps: []
resolver: lts-3.3

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Sep 7, 2015

That's a separate issue, thanks for reporting. I've fixed it on master.

Loading

@luigy
Copy link
Contributor Author

@luigy luigy commented Sep 7, 2015

Thanks! executables are fixed now

The "unregistering" still happens though, unless I run it twice, strange

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Sep 7, 2015

That's a known issue, #838, which is being worked on currently.

Loading

@luigy
Copy link
Contributor Author

@luigy luigy commented Sep 20, 2015

Nice! 11e02a8 fixes the "unregistering"

Loading

@luigy luigy closed this Sep 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants