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 doesn't rebuild enough when using Custom build-type #2040

Closed
mboes opened this issue Apr 17, 2016 · 5 comments
Closed

Stack doesn't rebuild enough when using Custom build-type #2040

mboes opened this issue Apr 17, 2016 · 5 comments

Comments

@mboes
Copy link
Contributor

@mboes mboes commented Apr 17, 2016

Steps to reproduce

Create a trivial stack project with the following Setup.hs (and setting build-type: Custom):

import Distribution.Simple

main = defaultMainWithHooks simpleUserHooks { postBuild = putStrLn "Hey!" }

Then stack build twice.

Expected

stack should run the preBuild/postBuild hooks each time stack build is called. In general these may be callouts to make or any other foreign build system, whose dependency graph is invisible to Cabal/Stack/GHC.

Actual

stack runs these hooks once only, unless Haskell source files change. Note that cabal-install does rerun these hooks every time. It's Stack's recompilation avoidance that seems to be the problem here.

@mboes
Copy link
Contributor Author

@mboes mboes commented Apr 17, 2016

One possible solution here could be to treat build-type: Custom specially, i.e. be less aggressive about recompilation avoidance in that particular case.

@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Apr 18, 2016

Yeah, special casing built-type: Custom for this makes sense to me.

@mgsloan mgsloan added this to the P2: Should milestone Apr 18, 2016
@mgsloan mgsloan added type: bug and removed type: enhancement labels Apr 18, 2016
@mboes
Copy link
Contributor Author

@mboes mboes commented Apr 18, 2016

Problem is, if package D has build-type: Custom, and the dependency chain in a multi-package project looks like A -> B -> C -> D, then the hooks will be rerun each time for D and presumably A, B, C become out-of-date and rebuild too? Likely no object files will be rebuilt, but the null build may take quite a bit more time.

What about another solution: take into account the extra-source-files field, and posit that build-type: Custom only ever needs to rerun if any of the sources files listed there (+ those files already taken into account) are newer. This is perhaps not correct in general, but should cover nearly every sane use case for using build hooks.

@mgsloan
Copy link
Contributor

@mgsloan mgsloan commented Apr 18, 2016

Yeah, though it seems to me like a strange behavior to toggle based on build-type. Perhaps changes to extra-source-files should always cause package dirtiness? It's better to have false positives than false negatives for dirtiness checking.

@mgsloan mgsloan added type: enhancement and removed type: bug labels Apr 18, 2016
judah pushed a commit to judah/stack that referenced this issue Jul 10, 2016
commercialhaskell#2040).

This is necessary for packages that use a custom Setup.hs
(`build-type: Custom`).  Previously, stack wouldn't rebuild the package
if the only changes were to the `extra-source-files`.

Stack was already marking the package as dirty if `data-files` changed;
this just hooks `extra-source-files` into the same mechanism.
judah pushed a commit to judah/stack that referenced this issue Jul 10, 2016
commercialhaskell#2040).

This is necessary for packages that use a custom Setup.hs
(`build-type: Custom`).  Previously, stack wouldn't rebuild the package
if the only changes were to the `extra-source-files`.

Stack was already marking the package as dirty if `data-files` changed;
this just hooks `extra-source-files` into the same mechanism.
borsboom added a commit that referenced this issue Jul 10, 2016
Let extra-source-files mark a package as dirty (#1891, #2040).
@borsboom
Copy link
Contributor

@borsboom borsboom commented Jul 10, 2016

I think this is resolved by the merge of #2362. Please re-open if not.

@borsboom borsboom closed this Jul 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.