- User Since
- Mar 21 2016, 2:34 AM (165 w, 6 d)
Sep 11 2017
Mar 27 2017
LGTM. I usually prefer to fix the more than 80 char warnings, but that's just a nitpick.
Mar 10 2017
I was thinking of implementing escaping but there is one more problem here. What I had mentioned earlier was only Unix/Bash kind of escaping. Even though might work across Unix shells, it may not work for Windows, the windows command line might have different conventions for escaping. For example, see this http://stackoverflow.com/questions/7760545/escape-double-quotes-in-parameter . It may be better idea if we have some working, tested and maintained code rather than researching and then implementing it from scratch, miss some cases and then keep fixing, maintaining etc. Maybe a good idea to check with someone in the cabal team who knows that code, though it may or may not be easy to pluck out that code. Overall this seems to be a pretty low return on investment fix and I have been too busy at work, so I am inclined to drop this at this point rather than pursuing further.
Feb 8 2017
Thanks @bgamari for quick response and for writing the code snippet too! However, my main point was whether this solution (i.e. --ghc-options) is an acceptable solution or we need to seek more discussion on the whole issue. From your response and implementation it seems to be acceptable to you at least? If so, I can happily implement it.
Not sure what to do with this change. The trac discussion suggested to start a GHC proposal process, but I have very little time on my hands to be able to drive that. I can at most try to figure out a way to implement --ghc-options as suggested and discussed above. If that is an acceptable option I will proceed to make the changes otherwise I will have to just drop this unless someone provides a way forward.
Jan 14 2017
- Fix doc formatting, add trac issue reference
Jan 8 2017
Couple more disclosures:
Jan 7 2017
Aug 31 2016
No problem. Thanks for the tips. Now I know what to do next time.
Aug 29 2016
Thanks! I agree with your suggestion. Now that you have accepted it, I am not sure if I should fix and upload again. I have a couple of process/phabricator related questions:
Aug 28 2016
Aug 25 2016
I agree, it can be fixed that way. But what I was worried about was that this will be a point fix for the doc targets only and not a general mechanism for other such problems. And make is hard to debug so we should venture more time only if we get a significant return.
Aug 24 2016
I uploaded another commit. I think I addressed all the comments. Please go through it again and let me know if there is anything which is inaccurate or needs to be reworked.
- Packages doc: address review comments by ezyang
Aug 23 2016
That's a general and a bit more difficult problem to solve. It's not just doc targets, it's true for any targets that's been disabled, that's the way build is system is designed. To be able to do that we will have to know which targets potentially exist but have been disabled. Also for each target we will perhaps want to print specific help info as well about how to enable it. It will require a lot more work.
Please pardon my ignorance. This was the first time I changed anything in GHC code base or used arc/phabricator. I hoped it will show separate commits like github. But I realized only after uploading that it shows only the combined diff. I have a related question, when I make more changes and upload to the same diff, what happens to the previous review/comment history, is it retained by the tool? Does it get affected in any way?
Aug 22 2016
Adding a few more commits related to package databases' documentation
- Update the documentation on package databases
- Move "package environments" section
- Retain a space between a flag and its argument