Fixed new haddock 2.2 - resolves partly https://github.com/haskell/cabal/issues/5232

[cartazio]

attempt at fixing #5232

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

Please also shortly describe how you tested your change. Bonus points for added tests!

[cartazio]

woops, initially based it on master rather than 2.2 for the PR, fixed that

[cartazio]

@hvr @alexbiehl @gbaz the more precise fix is also needed, but I also dont know how to wire up the warning logging to the usual output....

even this PR alone should fix up the main main issue in 2.2 cabal-install ... though the more polished one is needed to...

how do we get this IN and released?

[cartazio]

@23Skidoo thoughts?

[alexbiehl]

Sorry for the late reply. I think this is an OK way to go. Cabal doesn't give us too many opportunities to hook into error handling. But: I think we should really reuse error reporting from the hard failing one to have consistent look of error messages.

[cartazio]

Makes sense. I wasn’t sure how to do that. It still needs to do the no docs bit What would be a better than OK approach?

…

On Tue, May 29, 2018 at 4:51 PM Alexander Biehl ***@***.***> wrote: Sorry for the late reply. I think this is an OK way to go. Cabal doesn't give us too many opportunities to hook into error handling. But: I think we should really reuse error reporting from the hard failing one to have consistent look of error messages. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5269 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwgL9CuyeWa7WlrB1szln2qRhWrB9ks5t3bTsgaJpZM4TZLoe> .

[23Skidoo]

Should use warn instead of putStr[Ln].

[23Skidoo]

But: I think we should really reuse error reporting from the hard failing one to have consistent look of error messages.

See Distribution.Client.ProjectOrchestration.dieOnBuildFailures.

[cartazio]

Thx! I’ll see if I have time after Tuesday. But if you wanna donate this to a new contributor at zurihac please feel welcome to

…

On Sat, Jun 9, 2018 at 9:26 AM Mikhail Glushenkov ***@***.***> wrote: But: I think we should really reuse error reporting from the hard failing one to have consistent look of error messages. See Distribution.Client.ProjectOrchestration.dieOnBuildFailures. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5269 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwloKO5J8c-mzLEZcVr5msEyvkPyTks5t68z_gaJpZM4TZLoe> .

[cartazio]

so action items i'm gonna update this for today

1. dont run haddock when a package is empty

2. move to using warn

@23Skidoo hrmm, beyond adding warn, how do you propose i use/adapt the dieOnBuildFailures to this case?

[cartazio]

ok, i pushed some partially done changes,
I added to the haddock exports a "compute input files " function,
though i'm not sure how i get the arguments i need for it in the ProjectBuilding.hs file

haddockInputFilesFromLibrary :: Verbosity
            -> LocalBuildInfo
            -> ComponentLocalBuildInfo
            -> Library
            -> IO [FilePath]
haddockInputFilesFromLibrary  verbosity lbi clbi lib =
  map snd `fmap` getLibSourceFiles verbosity lbi lib clbi

[typedrat]

Superseded by #5459.