<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.hoenzb
        {mso-style-name:hoenzb;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
.MsoPapDefault
        {mso-style-type:export-only;
        margin-top:6.0pt;
        margin-right:0cm;
        margin-bottom:6.0pt;
        margin-left:0cm;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US">Nick,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US">Where in the wiki would you have looked for it? 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US">This isn’t at trick question.  It’s quite hard to know where to record info! 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US">S<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";mso-fareast-language:EN-US"><o:p> </o:p></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:ghc-devs-bounces@haskell.org]
<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> ghc-devs@haskell.org<br>
<b>Subject:</b> Re: Tests with compilation errors<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;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?)<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Thanks very much for sharing all of this.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;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:<o:p></o:p></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="mso-margin-top-alt:6.0pt;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">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 class="hoenzb">> --</span><br>
<span class="hoenzb">> Gintautas Miliauskas</span><br>
<span class="hoenzb">></span><br>
<span class="hoenzb">> _______________________________________________</span><br>
<span class="hoenzb">> ghc-devs mailing list</span><br>
<span class="hoenzb">> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a></span><br>
<span class="hoenzb">> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">
http://www.haskell.org/mailman/listinfo/ghc-devs</a></span><br>
<span class="hoenzb">></span><br>
<br>
<span class="hoenzb">--</span><br>
<span class="hoenzb">Regards,</span><br>
<br>
<span class="hoenzb">Austin Seipp, Haskell Consultant</span><br>
<span class="hoenzb">Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">
http://www.well-typed.com/</a></span><br>
<span class="hoenzb">_______________________________________________</span><br>
<span class="hoenzb">ghc-devs mailing list</span><br>
<span class="hoenzb"><a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a></span><br>
<span class="hoenzb"><a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a></span></span><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>