
#8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): akio, you seem to have something special about your environment (`DYNAMIC_BY_DEFAULT`?) I had to add `-dynamic` to the `ghc` invocations to reproduce. But a simpler test is {{{ rwbarton@morphism:/tmp$ ghc -c Test.hs rwbarton@morphism:/tmp$ ghc -c Test.hs -threaded compilation IS NOT required rwbarton@morphism:/tmp$ ghc -c Test.hs -debug compilation IS NOT required rwbarton@morphism:/tmp$ ghc -c Test.hs -eventlog rwbarton@morphism:/tmp$ }}} Technically the eventlog way is not actually RTS-only because it adds `-DTRACING` to the C compiler and C preprocessor options. If you had CPP in Test.hs that checked whether `TRACING` was defined, then recompiling the module to an object file (either in ghci or by ghc) really would have been necessary. So, there are a few possible resolutions: 1. Make `WayEventLog` a non-RTS only way in `wayRTSOnly`, which would suppress this ghci warning, on the grounds that modules can detect (via CPP) whether they were built with `-eventlog`. I think this would prevent linking `-eventlog` object files with non-`-eventlog` ones, though. 2. Don't change `wayRTSOnly`, and just change the test for that ghci warning to check something other than `wayRTSOnly` (e.g., treat `WayEventLog` specially). However this leaves us in the current mildly inconsistent state of affairs that `-eventlog` is considered in some sense (and is documented to be) a link-time only option, when in fact it affects compilation as well. 3. Implement `WayEventLog` in the same manner as `WayThreaded` and `WayDebug`. I don't know exactly what is (perhaps thomie can comment) but the latter two ways are not built by automatically enabling CPP options in ghc, even though the RTS is in fact full of `#ifdef THREADED` and `#ifdef DEBUG`. I assume there is some special logic in the build system for these. This potentially breaks people who were using `#ifdef TRACING` in their Haskell source, but hopefully there aren't any (it is undocumented after all). Personally I lean towards 3 if it isn't technically difficult to implement. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8123#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler