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

Setup.hs preprocessor run too late #946

Closed
gibiansky opened this Issue Sep 7, 2015 · 8 comments

Comments

Projects
None yet
2 participants
@gibiansky

gibiansky commented Sep 7, 2015

I have the following Setup.hs with build-type: Custom:

import           Distribution.Simple
import           System.Process (system)

main = defaultMainWithHooks
         simpleUserHooks { preConf = \args confFlags -> do
           system "./build-parser.sh"
           preConf simpleUserHooks args confFlags }

This generates a module named Reskin.Parser in src/Reskin/Parser.hs. If I don't include Reskin.Parser in other-modules, things work; if I do, stack complains that Parser.hs doesn't exist (instead of just running Setup.hs which generates Parser.hs in the right place).

This is using stack just upgraded today via stack upgrade --git. I can get this to work only if I run cabal configure

Is this a me problem or a stack problem?

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

Is it complaining and failing, or just complaining preemptively?

On Tue, Sep 8, 2015, 12:44 AM Andrew Gibiansky notifications@github.com
wrote:

I have the following Setup.hs with build-type: Custom:

import Distribution.Simpleimport System.Process (system)

main = defaultMainWithHooks
simpleUserHooks { preConf = \args confFlags -> do
system "./build-parser.sh"
preConf simpleUserHooks args confFlags }

This generates a module named Reskin.Parser in src/Reskin/Parser.hs. If I
don't include Reskin.Parser in other-modules, things work; if I do, stack
complains that Parser.hs doesn't exist (instead of just running Setup.hs
which generates Parser.hs in the right place).

This is using stack just upgraded today via stack upgrade --git. I can
get this to work only if I run cabal configure

Is this a me problem or a stack problem?


Reply to this email directly or view it on GitHub
#946.

@gibiansky

This comment has been minimized.

gibiansky commented Sep 8, 2015

It is failing. See below. It is warning about modules not being listed, and then trying to build without first configuring, resulting in an error when there's no Parser.hs because it hasn't been generated yet...

stack build
Warning: module not listed in ghc-reskin.cabal for 'ghc-reskin' component (add to other-modules):
    Reskin.Parser
ghc-reskin-0.1.0.0: build
Preprocessing executable 'ghc-reskin' for ghc-reskin-0.1.0.0...

/Users/silver/code/ghc-reskin/src/Reskin.hs:26:18:
    Could not find module ‘Reskin.Parser’
    Use -v to see a list of the files searched for.
@gibiansky

This comment has been minimized.

gibiansky commented Sep 8, 2015

If I run cabal configure first, then stack build, everything proceeds as normal.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

Did you modify the Setup.hs file after it was already configured? Can you try running stack clean && stack build and see what happens? stack definitely does a configure before calling build.

@gibiansky

This comment has been minimized.

gibiansky commented Sep 8, 2015

You're right, that works fine.

What's the "right" way to do this with stack/cabal? I have a happy-generated parser that should be regenerated if and only if it's actually changed. Maybe preConf is just the wrong build hook to use?

Perhaps this is really not something stack should handle. I'm not sure.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

I'm not certain to be honest, I've never tried it myself. In this case, stack is really just exposing the underlying Cabal library, so the solution should be the same for both. Ideally you'd like a way to tell Cabal "please run this command to generate this file, and rerun any time that source file has changed."

On the stack side: this is somewhat related to #914. I just proposed over there a stack build --reconfigure flag, which would probably solve the issue. How does that sound to you?

@gibiansky

This comment has been minimized.

gibiansky commented Sep 8, 2015

That seems reasonable. I can probably wrap my command in make or just check the timestamp manually to avoid erroneous recompiles on configure. With --reconfigure I could just always run stack build --reconfigure and it would do the right thing.

snoyberg added a commit that referenced this issue Sep 8, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Sep 8, 2015

OK, new --reconfigure flag added to master. It won't force your code to rebuild if there are no changes, but if the code is being rebuilt, it will start with a reconfigure, which seems like the right behavior in (virtually?) all cases.

@snoyberg snoyberg closed this Sep 8, 2015

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