Don't show source and object paths with the default verbosity.
No objection to this change, but just a related comment: in general, it would be great if everywhere we test verbosity there was an associated flag, and each verbosity level were equivalent to a collection of flags, just like -O.
@mpickering: The failing test should be fixed now.
@nomeata: I first named the flag -fshow-file-paths but I thought it was too general (could be package files, config files, library files, etc.). Modules don't really have paths but the latter are shown when modules are compiled (and from the showModMsg function) so it was the most descriptive name I came up with. Maybe we should have both -fshow-source-paths and -fshow-object-paths.
@simonmar: do you think it is worth creating a specific ticket for this (as a newcomer task maybe)?
Hmm, sorry for jumping in the middle of discussion at this last moment. I just wanted to tell you than in haskell-mode in Emacs we filter out everything after module name, so it looks like this:
[1 of 3] Compiling SH_Overlap4_B [2 of 3] Compiling SH_Overlap4_A [3 of 3] Compiling SH_Overlap4
Now, for debugging purposes I sometimes needed the path information. It was useful for a multiplatform setup where I had two T modules, one in posix/T.hs and other in windows/T.hs. Path information was useful to check if correct module was loaded this time.
After you remove the path what is left is just three cases:
[1 of 3] Compiling A (.hs -> nothing) [2 of 3] Compiling B (.hs -> .o) [3 of 3] Compiling C[sig] (.hsig -> nothing)
Note that 1. and 2. informs if module is compiled or interpreted (I guess, I'm not sure). Case 3. is redundant because it says sig two times.
To sum it up:
- path info is useful in cases where configuration uses directories for functionality switching
- interpreted vs compiled is arguably not that useful, I have never needed this info
- there are tools already to filter out this whole information
I'd like to propose to have the functionality work as follows:
In non-verbose mode:
[1 of 3] Compiling SH_Overlap4_B
In verbose mode:
[1 of 3] Compiling SH_Overlap4_B ( windows/SH_Overlap4_B.hs, dist/build/output/SH_Overlap4_B.o )
You may also consider not adding a flag with such marginal utility and just use current verbosity setting.
Just .02$ about how this works in haskell-mode.
To tell whether GHCi is picking up .o files for a module, or falling back to interpreting. Particularly if you're using :set -fobject-code, or if you've compiled the project in the past and you want to know whether GHCi is using the compiled artifacts.