#1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by mgsloan): Hi, thanks for the response Andy! Handily, I already had a minimal repro for this from back when I initially started working on coverage support in stack: https://github.com/mgsloan /multi-test-suite In particular: {{{ mgsloan@computer:~/fpco/multi-test-suite$ cabal test --ghc-options -fhpc # ...mgsloan@computer:~/fpco/multi-test-suite$ hpc report multi-test- suite-test.tix hpc: can not find Main in ["./.hpc"] mgsloan@computer:~/fpco/multi-test-suite$ hpc report multi-test-suite- test-2.tix 50% expressions used (1/2) 100% boolean coverage (0/0) 100% guards (0/0) 100% 'if' conditions (0/0) 100% qualifiers (0/0) 100% alternatives used (0/0) 100% local declarations used (0/0) 100% top-level declarations used (1/1) }}} This issue will also affect cabal files that have other stanzas like executables and benchmarks. I added a folder called sub-package to multi- test-repo, actually debug / test out a different stack coverage related issue. The only reasonable way I can think of to fix this is to add a flag to GHC, which takes the name to use for the mix file folder. This won't directly fix the problem with current Cabal, but it would allow future version of Cabal to pass the info so that this issue is resolved. I'm not sure what to call the flag - it doesn't necessarily need to be specific to HPC - since there might be other places in GHC that benefit from knowing the cabal component. So, I'm thinking either `-component- name`, or `-hpc-component-name`. I took a look at Cabal's current invocations of GHC to see if there is any way for GHC to know that it's building a particular executable component. Unfortunately, I don't see any arguments that would make a good source for this info: {{{ /usr/local/bin/ghc --make -no-link -fbuilding-cabal-package -O -j8 -static -outputdir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -odir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -hidir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -stubdir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -i -idist/build /multi-test-suite-test/multi-test-suite-test-tmp -itest -idist/build/autogen -Idist/build/autogen -Idist/build/multi-test-suite- test/multi-test-suite-test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.8.1.0-4f7206fd964c629946bb89db72c80011 -package-id multi-test- suite-0.1.0.0-inplace -XHaskell2010 test/Spec.hs -threaded -rtsopts '-with-rtsopts=-N' -fhpc }}} (Sorry, the naming isn't all that clear, `multi-test-suite-test` is the name of the component) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1853#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler