<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>