Hi Robert, I pushed my touched-up version of your branch to master! (See commits a62ddb748f–caa366ec23.) Now I will enjoy closing all those patches. :)
I hope all my changes are okay. Besides the changes to “ghc-8.6”, I mostly altered formatting, descriptions, and commit messages to better fit our conventions. I’ve added a few comments below. Robert Vollmert <r...@vllmrt.net> writes: > Hi Timothy, > >> On 6. Aug 2019, at 06:29, Timothy Sample <samp...@ngyro.com> wrote: >> >>> #36692: GHC version 8.6.5 (just as a package for now, not used to build >>> anything) >> >> I made some bigger changes here. Mostly, I made use of >> “substitute-keyword-arguments” to reuse more code from “ghc-8.4”. >> >> Why do you use “patch” instead of “substitute*” to disable the failing >> tests? I see from your previous patches that you used to do it with >> “substitute*”. > > It would be ok to go back to the old state. I moved to a patch over the > process of getting the build to pass, which involved skipping more tests. > That said, substitute has several downsides compared to patches: > - patch is easier to read Personally I find them about the same, but my impression is that the “substitute*” approach is more common. I used it to try to be more consistent. > - patch doesn’t fail silently This is a real problem, and there was a recent discussion on changing the semantics of “substitute*” to fix this (I can’t find it now, though). We would probably find a lot of unnecessary calls to “substitute*” if we could easily see when it does nothing. >>> no ticket: Skip tests for three Haskell packages that fail on i686 only >>> (and seem harmless): ghc-trifecta, ghc-yaml, ghc-libmpd-haskell. >> >> This seems reasonable to me, though I suppose it would be better to only >> skip them when building for i686. It looks like we only do this >> rarely (e.g., the “icu4c” package), so maybe it’s not a big deal. > > I’ll keep that in mind for next time I run into a similar issue. > >> Is there any more info about “ghc-trifecta”? The other two have nice >> comments that tell me that upstream is aware of the problem, and that it >> might be fixed in the future. > > That one is a rather opaque build failure kind of thing related to doctests: > > They fail to build on i686: > > doctests: > ByteCodeLink.lookupCE > During interactive linking, GHCi couldn't find the following symbol: > > lenszm4zi16zi1zmJLUwQ4zzqmnaKkc25AByaCJ_ControlziLensziTH_makeClassy_closure > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi. > If you suspect the latter, please send a bug report to: > glasgow-haskell-b...@haskell.org > > Test suite doctests: FAIL > > I spent a bit of time digging, then gave up. That’s no problem. I just wanted to be sure that you looked and didn’t see anything obvious. We can investigate it later or it may get fixed upstream. > Thanks for the review. You’re welcome! -- Tim