<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier <span dir="ltr"><<a href="mailto:code@funwithsoftware.org" target="_blank">code@funwithsoftware.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/14/16 9:26 PM, Michael Snoyman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings.<br>
</blockquote>
<br></span>
AFAIK, this behavior is not clearly documented.<span class=""><br>
<br></span></blockquote><div><br></div><div>I'd be happy to add a comment. Do you have a recommendation of somewhere to put such an explanation that would make sense?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Save the output to a log file, and then display all of the log files to the user at the end, which would result in looking for a needle in a haystack in many cases<br>
</blockquote>
<br></span>
Is there any harm in having an option for this?  If the number of local packages is small (3 in my case) and there are not a huge number of warnings, this still seems quite manageable.<span class=""><br>
<br></span></blockquote><div><br></div><div>Perhaps a simple option to --dump-log-output, which at the end of a build prints all logs from all local packages? That's certainly possible, though I haven't touched that part of the code in quite a while.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I put together the initial code for running builds, I chose (1), which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to).<br>
</blockquote>
<br></span>
I'm used to using "cabal sandbox add-source" to add dependencies that I have locally checked out (e. g. because I've modified them, or because they aren't released on Hackage yet).  cabal doesn't printing warnings for those dependencies, but it does always print warnings for the one package that I'm working on.  (The one in the current directory.)<br>
<br>
As far as I know, stack doesn't make a distinction between "the package I'm working on now" and other dependencies which are checked out locally.  They all go in "packages" in the stack.yaml.<br>
<br>
So, although it's not an apples-to-apples comparison, it is different behavior than I was getting with my cabal workflow.<br>
<br></blockquote><div><br></div><div>There is the extra-dep field in packages, but it wouldn't affect this specific case. But really, the way you tell Stack "the package I'm working on now" is by specifying it as a target on the command line, which _does_ work: `stack build http-client-tls` in my example above does in fact display the output on the console.</div><div><br></div><div>Thanks for the feedback.</div><div><br></div><div>Michael</div></div></div></div>