<div dir="ltr">I skimmed Austin's message again and then began the hunt from the main wiki page. I ended up with these open tabs:<div><br></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries</a><br></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace">https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace</a><br></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries#Classifyingbootpackages">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries#Classifyingbootpackages</a><br></div><div><a href="https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Details">https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Details</a><br></div><div><br></div><div>Nothing jumped out at me as "just the right spot". The main mismatch seems to be the motivation of the text; Austin's message had more of "this is why it is the way it is" than I see on the wiki. Also, I didn't notice any mention of the details that Austin gave about validate.sh.</div><div><br></div><div>HTH</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 31, 2014 at 3:25 AM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">Nick,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">Where in the wiki would you have looked for it? 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">This isn’t at trick question.  It’s quite hard to know where to record info! 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">S<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>]
<b>On Behalf Of </b>Nicolas Frisby<br>
<b>Sent:</b> 30 October 2014 22:42<br>
<b>To:</b> Austin Seipp<br>
<b>Cc:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> Re: Tests with compilation errors<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
This reply is very informative! Could you put it on the wiki for me to digest at a later date? (Or maybe there's already a consolidated place to find it all on there?)<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Thanks very much for sharing all of this.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Thu, Oct 30, 2014 at 2:19 PM, Austin Seipp <<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Thu, Oct 30, 2014 at 6:48 AM, Gintautas Miliauskas<br>
<<a href="mailto:gintautas.miliauskas@gmail.com" target="_blank">gintautas.miliauskas@gmail.com</a>> wrote:<br>
> Going through some validate.sh results, I found compilation errors due to<br>
> missing libraries, like this one:<br>
><br>
> =====> stm052(normal) 4088 of 4108 [0, 21, 0]<br>
> cd ../../libraries/stm/tests &&<br>
> 'C:/msys64/home/Gintas/ghc/bindisttest/install   dir/bin/ghc.exe'<br>
> -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db<br>
> -rtsopt<br>
> s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs  -package stm<br>
>>stm052.comp.stderr 2>&1<br>
> Compile failed (status 256) errors were:<br>
><br>
> stm052.hs:10:8:<br>
>     Could not find module ‘System.Random’<br>
>     Use -v to see a list of the files searched for.<br>
><br>
> I was surprised to see that these are not listed in the test summary at the<br>
> end of the test run, but only counted towards the "X had missing libraries"<br>
> row. That setup makes it really easy to miss them, and I can't think of a<br>
> good reason to sweep such tests under the rug; a broken test is a failing<br>
> test.<br>
<br>
Actually, these tests aren't broken in the way you think :) It's a bit<br>
long-winded to explain...<br>
<br>
Basically, GHC can, if you let it, build extra dependencies in its<br>
build process, one of which is the 'random' library. 'random' was not<br>
ever a true requirement to build GHC (aka a 'bootlib' as we call<br>
them). So why is this test here?<br>
<br>
Because 'random' was actually a dependency of the Data Parallel<br>
Haskell package, and until not too long ago (earlier this year),<br>
`./validate` built and compiled DPH - with all its dependencies;<br>
random, vector, primitive - by default. This actually adds a pretty<br>
noticeable time to the build (you are compiling 5-8 more libraries<br>
after all), and at the time, DPH was also not ready for the<br>
Applicative-Monad patch. So we turned it off, as well as the<br>
dependencies.<br>
<br>
Additionally, GHC does have some 'extra' libraries which you can<br>
optionally build during the build process, but which are turned off by<br>
default. Originally this was because the weirdo './sync-all' script<br>
used to not need everything, and 'stm' was a library that wasn't<br>
cloned by default.<br>
<br>
Now that we've submoduleified everything though, these tests and the<br>
extra libraries could be built by default. Which we could certainly<br>
do.<br>
<br>
> How about at least listing such failed tests in the list of failed tests of<br>
> the end?<br>
<br>
I'd probably be OK with this.<br>
<br>
> At least in this case the error does not seem to be due to some missing<br>
> external dependencies (which probably would not be a great idea anyway...).<br>
> The test does pass if I remove the "-no-user-package-db" argument. What was<br>
> the intention here? Does packaging work somehow differently on Linux? (I'm<br>
> currently testing on Windows.)<br>
<br>
I'm just guessing but, I imagine you really don't want to remove<br>
'-no-user-package-db' at all, for any platform, otherwise Weird Things<br>
Might Happen, I'd assume.<br>
<br>
The TL;DR here is that when you build a copy of GHC and all the<br>
libraries, it actually *does* register the built packages for the<br>
compiler... this always happens, *even if you do not install it*. The<br>
primary 'global' package DB just sits in tree instead, under<br>
./inplace.<br>
<br>
When you run ./validate, what happens is that after the build, we<br>
actually create a binary distribution and then test *that* compiler<br>
instead, as you can see (obviously for a good reason - broken bindists<br>
would be bad). The binary distribution obviously has its own set of<br>
binary packages it came with; those are the packages you built into it<br>
after all. The reason we tell GHC to ignore the user package db here<br>
is precisely because we *do not* want to pick it up! We only want to<br>
test the binary distribution with the packages *it* has.<br>
<br>
Now you might say, well, Austin, the version numbers are different!<br>
How would it pick that up? Not always... What if I built a copy of GHC<br>
HEAD today, then built something with it using Cabal? Then that will<br>
install into my user package database. Now I go back to my GHC tree<br>
and hack away _on the same day_ and run './validate'... the version<br>
number hasn't changed *at all* because it's date based, meaning the<br>
binary distribution could certainly pick up the previously installed<br>
libraries, which I installed via the older compiler. But I don't want<br>
that! I only want to run those tests with the compiler I'm validating<br>
*now*.<br>
<br>
I imagine the reason you see this test pass if you remove this<br>
argument is precisely for this reason: it doesn't fail because it's<br>
picking up a package database in your existing environment. But that's<br>
really, really not what you want (I'd be surprised if it worked and<br>
didn't result in some horrible error or crash).<br>
<br>
> On a related note, how about separating test failures from failing<br>
> performance tests ("stat too good" / "stat not good enough")? The latter are<br>
> important, but they seem to be much more prone to fail without good reason.<br>
> Perhaps do some color coding of the test runner output? That would also<br>
> help.<br>
<br>
I also think this is a good idea.<br>
<span style="color:#888888"><br>
<span>> --</span><br>
<span>> Gintautas Miliauskas</span><br>
<span>></span><br>
<span>> _______________________________________________</span><br>
<span>> ghc-devs mailing list</span><br>
<span>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a></span><br>
<span>> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">
http://www.haskell.org/mailman/listinfo/ghc-devs</a></span><br>
<span>></span><br>
<br>
<span>--</span><br>
<span>Regards,</span><br>
<br>
<span>Austin Seipp, Haskell Consultant</span><br>
<span>Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">
http://www.well-typed.com/</a></span><br>
<span>_______________________________________________</span><br>
<span>ghc-devs mailing list</span><br>
<span><a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a></span><br>
<span><a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a></span></span><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
</div></div></div>
</div>
</div>

</blockquote></div><br></div>