Skip to content

A case when stack does not rebuild but I think it should #2339

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

Closed
harendra-kumar opened this issue Jul 6, 2016 · 6 comments
Closed

A case when stack does not rebuild but I think it should #2339

harendra-kumar opened this issue Jul 6, 2016 · 6 comments

Comments

@harendra-kumar
Copy link
Collaborator

I have a path-io specified as a local package with extra-dep as true in a package called path-test:

packages:
- '.'
- location: ../../github/path-io
  extra-dep: true

path-io has a stack.yaml of its own and when I make changes in that package I first build and test it using that stack.yaml. After that if I come back to the path-test package and do a stack build then it does not rebuild. If I do a stack clean in the path-io package (i.e. using path-io's stack-yaml) and then do a stack build in path-test then it rebuilds fine.

I am not sure why the path-test setup gets impacted by the path-io setup or whether it should.

@harendra-kumar harendra-kumar changed the title A case when stack does not rebuild but it I think it should A case when stack does not rebuild but I think it should Jul 6, 2016
@mgsloan
Copy link
Contributor

mgsloan commented Jul 20, 2016

There may not be any bugs here, as long as it's using the exact same dependencies. Definitely something that should get tested more!

Is it not rebuilding when there's definitely a difference in the build?

@harendra-kumar
Copy link
Collaborator Author

Yes, any new changes in path-io do not reflect in the path-test executable because it does not get rebuilt at all if I built path-io independently earlier.

@mgsloan mgsloan added this to the P2: Should milestone Jul 26, 2016
@ghost
Copy link

ghost commented Feb 16, 2017

Is there some hack workaround, that doesn't involve stack clean, such as telling each stack build to use its own package dbs?

@ghost
Copy link

ghost commented Feb 17, 2017

I will try --force-dirty. Also, I may not be using stack properly, as it might require that I increase the version number of the package (e.g. path-io) in its cabal header, so that downstream packages know that the package has changed?

@ghost
Copy link

ghost commented Feb 17, 2017

Bumping cabal version is a sufficient work around for now for me. --force-dirty didn't save much time relative to stack clean. stack might be behaving correctly by assuming that an upstream library did not need to be rebuilt unless its version number changed. Consider closing this issue and documenting that behavior instead.

@mpilgrem
Copy link
Member

mpilgrem commented Mar 3, 2024

I am closing this given the passage of time and because extra-deps are no longer specified using the packages key.

@mpilgrem mpilgrem closed this as completed Mar 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants