<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 9/14/16 10:39 PM, Michael Snoyman wrote:<br>
<blockquote
cite="mid:CAKA2JgJ=C_F9JU=fRLE7dXRMJVOeVWe=TLzdfKVTn6qpAoOGZw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Sep 15, 2016 at 8:25 AM,
Patrick Pelletier <span dir="ltr"><<a
moz-do-not-send="true"
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>
</div>
</blockquote>
<br>
Probably either in:<br>
<br>
<a class="moz-txt-link-freetext" href="https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command">https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command</a><br>
<br>
or:<br>
<br>
<a class="moz-txt-link-freetext" href="https://docs.haskellstack.org/en/stable/build_command/">https://docs.haskellstack.org/en/stable/build_command/</a><br>
<br>
or both.<br>
<br>
<blockquote
cite="mid:CAKA2JgJ=C_F9JU=fRLE7dXRMJVOeVWe=TLzdfKVTn6qpAoOGZw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
Yes, that would at least meet my needs.<br>
<br>
<blockquote
cite="mid:CAKA2JgJ=C_F9JU=fRLE7dXRMJVOeVWe=TLzdfKVTn6qpAoOGZw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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.</div>
</div>
</div>
</div>
</blockquote>
<br>
Right. My understanding is that extra-dep is for packages to fetch
from Hackage that are outside the current resolver. (Cabal doesn't
really have an equivalent option, since its implicit resolver is
"everything in hackage.") On the other hand, "cabal sandbox
add-source" is for packages on the local filesystem.<br>
<br>
<blockquote
cite="mid:CAKA2JgJ=C_F9JU=fRLE7dXRMJVOeVWe=TLzdfKVTn6qpAoOGZw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> 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>
</div>
</div>
</blockquote>
<br>
Thanks! That (along with the tip about --pedantic) is good to know.<br>
<br>
--Patrick<br>
<br>
</body>
</html>