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 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 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 commented Apr 18, 2016

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

@mboes
Copy link
Contributor Author

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

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

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

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