`stack build --ghc-output` (or similar) to print GHC output during a build

[spinda]

Provide an option to pipe GHC's output to the terminal to better keep track of progress, instead of hanging on Cabal-1.22.4.0: build for dependencies that take some time to compile.

[snoyberg]

We already have logic in place to send output to stdout under specific circumstances (namely: on the terminal, only one package left to build, and it's a "wanted" package). Adding a flag to simply override that logic with "always output to stdout" is trivial, though the result will likely not be what you're looking for unless you also use --jobs 1.

@chrisdone Thoughts?

[spinda]

although the result will likely not be what you're looking for unless you also use --jobs 1

As long as it gives some indication of GHC making progress, it's helpful.
Perhaps, in the multi-jobs context, output lines could be prefixed with the
name of the package generating them?

On Fri, Jun 26, 2015, 03:21 Michael Snoyman notifications@github.com
wrote:

We already have logic in place to send output to stdout under specific
circumstances (namely: on the terminal, only one package left to build, and
it's a "wanted" package). Adding a flag to simply override that logic with
"always output to stdout" is trivial, though the result will likely not be
what you're looking for unless you also use --jobs 1.

@chrisdone https://github.com/chrisdone Thoughts?

—
Reply to this email directly or view it on GitHub
#426 (comment)
.

[chrisdone]

Yeah, outputting interleaved GHC output would be a bit messy. We could indeed prefix lines, that was discussed once. It might not be too bad.

[snoyberg]

@spinda This part of the code base is pretty isolated. You interested in giving a crack at a PR on it? I can give you pointers of where to start.

[spinda]

@snoyberg I'm traveling from Friday to Monday, but if the delay isn't an issue then I'd be happy to have a go at it.

[snoyberg]

Shouldn't be a problem at all. When you're ready to look into this, check out Stack.Build.Execute and look for withLogFile and console.

[chrisdone]

👍

[mgsloan]

This may well be an overengineered solution, but it seems like it ought to be possible to have uninterleaved GHC output if some of it is delayed. Here's how this would work:

1. The first package being built would get control of stdout, so you get to see its live progress.

2. When that package finishes building, and does so successfully, the output from the other builds that finished can be outputted in bulk.

3. Then, it'd pick the next oldest build to get control over stdout (and it'll dump what it has so far for it). This makes it likely that you'll get the progress output from the package build that's holding things up. Continue with step 2.

Stack messages and logging would get interleaved with the ghc output, but that seems rather reasonable to me, if line buffered.

[snoyberg]

@mgsloan I'm -1 on that solution, it seems like it's contrary to the stated goal of this issue: get regular output to stdout as long as a build is occurring. Delaying output from other processes would impair that. Additionally, implementing the solution you've described would be very difficult to do without introducing the possibility of significant memory usage or hurting performance in the common case.

[mgsloan]

Agreed, the complication isn't worth it.

[snoyberg]

@spinda Are you still planning on looking into this?