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

Can't display -ddump-splices result. #4225

Closed
waddlaw opened this issue Aug 11, 2018 · 4 comments
Closed

Can't display -ddump-splices result. #4225

waddlaw opened this issue Aug 11, 2018 · 4 comments

Comments

@waddlaw
Copy link
Contributor

@waddlaw waddlaw commented Aug 11, 2018

$ stack build --ghc-options='-ddump-splices'

I want to display on the standard output, not to save to a file.

Question

Why does the extraBuildOptions function specify the " -ddump-hi -ddump-to-file" option by default?

extraBuildOptions wc bopts = do
    colorOpt <- appropriateGhcColorFlag
    let ddumpOpts = " -ddump-hi -ddump-to-file"
        optsFlag = compilerOptionsCabalFlag wc
        baseOpts = ddumpOpts ++ maybe "" (" " ++) colorOpt
    if toCoverage (boptsTestOpts bopts)
      then do
        hpcIndexDir <- toFilePathNoTrailingSep <$> hpcRelativeDir
        return [optsFlag, "-hpcdir " ++ hpcIndexDir ++ baseOpts]
      else
        return [optsFlag, baseOpts]

If remove this option, I think it will work as expected.

Stack version

$ stack --version
Version 1.10.0, Git revision 3b61926935c28efd10c8e6870f927a7d8eb5523c (dirty) (6119 commits) x86_64 hpack-0.29.6
@mattaudesse
Copy link
Member

@mattaudesse mattaudesse commented Aug 11, 2018

Thanks @waddlaw - that seems like a really good question and I'm not sure what the answer should be!

I think @borsboom might be the best person to ask since that setting seems to have been added in 6e65345.

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Aug 13, 2018

It's necessary to grab information available in the HI dump files, like addDependentFile information. The alternative would require an extra executable of the ghc executable for each .hi file, which is prohibitively expensive. I agree that the current situation is far from ideal, but it's AFAIK the best trade-off we have.

@waddlaw
Copy link
Contributor Author

@waddlaw waddlaw commented Aug 17, 2018

Thanks @snoyberg

What about providing stack build --ddump-dir option. For example, following command run listed the outputed dump files.

$ find $(stack path --dist-dir) -name "*.dump-*"
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Test.dump-simpl
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Ins.dump-stg
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Lib.dump-stg
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Ins.dump-simpl
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Lib.dump-simpl
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Test.dump-stg
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/src/Lib.dump-splices
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/autogen/Paths_th_example.dump-stg
.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/.stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/autogen/Paths_th_example.dump-simpl

if these file move to the specified dump-dir, I think better than now (Easy to understand the output location.). Perhaps not strictly correct the above result, but very useful for me. What do you think about this?

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Aug 19, 2018

I'd be OK with such a PR. It may be simpler to copy the files from where they're currently output by GHC to a new location, instead of trying to convince GHC to use a new directory and then parse it. Are you interested in taking a stab at a PR?

@waddlaw waddlaw mentioned this issue Aug 19, 2018
2 of 2 tasks complete
snoyberg added a commit that referenced this issue Aug 20, 2018
Add the ddump-dir option/config value #4225
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.

4 participants