- User Since
- Apr 27 2016, 1:39 PM (181 w, 2 d)
Mon, Oct 7
Jun 25 2019
Apr 19 2019
Apr 16 2019
Apr 2 2019
Mar 9 2019
Mar 4 2019
Dec 22 2018
I think the only question to resolve is whether it is ok to build haddock and ghcTags at stage1 How do you want to resolve this without leaving this patch in limbo?
Dec 20 2018
Dec 19 2018
@mpickering Thank you. I've left a few more comments. The question about moving ghcTags and haddock to Stage1 is the biggest. I don't know whether this is the right solution in the long term, and why Make's behaviour is different. Please clarify.
Dec 18 2018
I think I fixed things up now.
Dec 17 2018
Thanks, Alp! I think this is ready to land.
Dec 16 2018
Thanks Andrey, I managed to apply your suggestions and things appear to work smoothly still. I'll try a clean rebuild overnight.
@mpickering Thanks for trying to build Stage3 GHC! I've never tried it. I've left a bunch of comments.
Dec 15 2018
Looks good to me, thank you!
Some of your comments apply to the contents that was already there, and I don't feel like using this diff to freshen up the README entirely.
Dec 14 2018
I love the new docs, @alpmestan, thank you! I've left a few comments.
Dec 11 2018
Many thanks, @alpmestan! All looks great now.
Dec 10 2018
What a nice little build rule. We could add some more intelligence (see my comments), although what you already have is very useful too.
Where else do you want this to be documented?
This looks great. Thank you for the patch!
Hope that's enough to fix the issue.
Dec 7 2018
@alpmestan Awesome, thank you!
Dec 6 2018
@alpmestan Thank you! Looks perfectly reasonable to me.
@harpocrates Thank you for the patch.
@alpmestan Many thanks! Your patch looks great now.
Dec 5 2018
Dec 4 2018
@alpmestan Many thanks! In general this looks great, but I left a few comments/questions for you.
Dec 2 2018
And another thumb-up from me. Thanks @harpocrates!
Nov 28 2018
Thanks! Sure, let's bump the bounds.
Thanks @alpmestan, I agree with your thoughts.
Nov 27 2018
Looks good to me!
Nov 26 2018
Thanks! Yes, that's the right solution for now, but I'm happy to discuss/help with a better design.
Nov 22 2018
Let me capitalise the title, since Hadrian is a name :-)
@alpmestan Many thanks, this is a very helpful note.
Like @bgamari, I'd like to have a note about wrappers somewhere in the code, as otherwise it's always a matter of googling for hours in order to find out more information about them.
Nov 20 2018
Thank you! I believe this can now be merged.
Thank you! This looks good to me, although we should remember to merge this commit with Hadrian: prefix, since it's a Hadrian-only commit.
One more thing: we'd like to follow a convention that all Hadrian-only commits are prefixed with Hadrian: . I guess renaming this diff should be sufficient for it to land with the right commit message.
@harpocrates Thank you! The newly added comments and simplifications to the docs rule are very helpful.
Nov 14 2018
Additionally, I noticed that there Hadrian doesn't generate the short wrapper shell script the make-based system used to produce
Nov 13 2018
@harpocrates Many thanks! Apologies for taking so long to review. I've left a few minor comments, mostly just trying to make this patch a bit simpler.
Oct 27 2018
@watashi Thank you! Generally this looks good, but if possible I would like to avoid baking in the special case package /= rts (see my comment). Can this be specified in rts.cabal.in instead?
Oct 26 2018
@alpmestan I'm happy this fixes Hadrian, but I feel unqualified to review this patch from the GHC perspective. In my opinion, the way compareByPreference and integer-wired-in interact is questionable and error-prone (both before and after this patch), which should probaby be discussed in a separate GHC ticket.
Oct 25 2018
@alpmestan Great! Is there a way to migrate our AppVeyor and Travis scripts too?
Oct 24 2018
@alpmestan Thank you, this looks good to me. However, have we lost all CI support with the move from GitHub? Can we fix the CI first?