5

I suspect this is either a problem with ghc or cabal-install:

I used to get build information in such a format:

Resolving dependencies...
    Configuring ltk-0.8.0.6...
    Building ltk-0.8.0.6...
    Preprocessing library ltk-0.8.0.6...
    [ 1 of 12] Compiling Graphics.UI.Frame.Panes ( src/Graphics/UI/Frame/Panes.hs, dist/build/Graphics/UI/Frame/Panes.o )
    [ 2 of 12] Compiling Graphics.UI.Editor.Parameters ( src/Graphics/UI/Editor/Parameters.hs, dist/build/Graphics/UI/Editor/Parameters.o )
    [ 3 of 12] Compiling Control.Event    ( src/Control/Event.hs, dist/build/Control/Event.o )
    [ 4 of 12] Compiling MyMissing        ( src/MyMissing.hs, dist/build/MyMissing.o )
    [ 5 of 12] Compiling Graphics.UI.Editor.Basics ( src/Graphics/UI/Editor/Basics.hs, dist/build/Graphics/UI/Editor/Basics.o )
    [ 6 of 12] Compiling Graphics.UI.Editor.MakeEditor ( src/Graphics/UI/Editor/MakeEditor.hs, dist/build/Graphics/UI/Editor/MakeEditor.o )
    [ 7 of 12] Compiling Text.PrinterParser ( src/Text/PrinterParser.hs, dist/build/Text/PrinterParser.o )

However, now I get this type of build output:

Configuring binary-shared-0.8.3...
Configuring cairo-0.12.5.1...
Building binary-shared-0.8.3...
Building cairo-0.12.5.1...
Installed binary-shared-0.8.3
Configuring ghc-paths-0.1.0.9...
Building ghc-paths-0.1.0.9...
Installed ghc-paths-0.1.0.9
Configuring glib-0.12.5.0...

As you can see, cabal-install or ghc, whichever is causing the problem, seems to be inducing undesirable laconism now. According to my cabal config, I am running at a default verbosity level of 1. Is there some configuration option that could have caused this particular behavior? In other words, how can I restore the original behavior? Version 1.18.0.2

eazar001
  • 1,572
  • 2
  • 16
  • 29
  • By chance are you using a cabal sandbox now? The output you're printing are from installing *packages*, while your original output was from building *modules* within a package. It looks like the minimal output snippet is from the initial install of packages to the sandbox, and after those finish you should see the output you're expecting. – John L Feb 20 '14 at 06:52
  • @JohnL, No I'm not in a sandbox. For example I just installed `hoogle`, and there is no module compilation output, as expected when installing `hoogle`. This behavior occurs whether or not I am in a sandbox. – eazar001 Feb 20 '14 at 06:58
  • @JohnL, i.e. if I were to install `leksah` again, as from the desired 'verbose' output, it would not display the 'rich' output as demonstrated above. I have no idea what caused this side effect. – eazar001 Feb 20 '14 at 07:00
  • Also, I used to get the original output all the time, globally, or in a sandbox. – eazar001 Feb 20 '14 at 07:09
  • 3
    Have you turned on `-j` to parallelize builds? In that case, the more informative logs are just stored in a text file instead of having the output interleaved on stdout. – Michael Snoyman Feb 20 '14 at 08:06
  • 1
    @MichaelSnoyman, I have not explicitly passed a `-j` flag to any of my builds, but my `config` is initialized with `jobs: $ncpus`. This is default behavior though, isn't it? – eazar001 Feb 20 '14 at 08:16
  • 1
    @MichaelSnoyman, you were right!! After commenting out the `jobs` parameter in my config file, `stdout` regained the information I was accusomted to. Thanks. – eazar001 Feb 20 '14 at 08:19

1 Answers1

5

Thanks to @Michael Snoyman for pointing out that configuring a jobs parameter or explicitly passing it as a -j flag will redirect much of the information that pertains to build output to a text file. More information is available here.

eazar001
  • 1,572
  • 2
  • 16
  • 29