-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Haddock: Generate haddock for components #5226
Conversation
4939624
to
2d2a36e
Compare
@merijn this should fix your problem. |
You're a hero :) |
43310a7
to
712273d
Compare
(This resolves #4506) |
Needs a changelog note and maybe some tweaks to docs. |
As this extends the @23Skidoo this requires making a decision whether we want to target Cabal-2.2.1 or Cabal-3.0 for this (otherwise backward-compatible) CLI enhancement |
I've been using this patch the past few days and it seems to work fine, but introduces one silly issue. With |
Ok, my bad. I just didn't wanna rebuild all of cabal to test that. |
Currently settings `documentation: true` enables documentation generation via haddock for your whole package, including tests and benchmarks. However, there are additional flags to control generation of documentation for this "second class" documentation targets, which are currently not honored at the cabal-install side of things. Namely, `tests`, `benchmarks`, `executables`, etc. provided under the `haddock` section in your `$CABAL_HOME/config`. This patch adds a more sensible approach to documentation generation via haddock. Also enabling `new-haddock` to generate documentation for single components instead whole packages. The behaviour works like this: - Setting `documentation: true` or passing `--enable-documentation` to cabal-install enable documentation for any component in the build plan honoring the respective flags for tests, benchmarks, exes, foreignlibs, etc. - Invoking new-haddock with a target selector will make sure the respective flags for "second class" doc targets are set correctly. E.g. $ new-haddock tests Will generate documentation for the testsuite of your package event if you have `tests: false` in your haddock section.
712273d
to
4466310
Compare
@merijn I corrected the faulty behaviour. |
works now \o/ |
@23Skidoo I added change log entry and documentation. |
Incidentally, this PR seems to fix a truckload of issues with new-build's dependency tracking for me. I've been struggling to figure out what was going on with new-repl and new-build being weird about whether stuff had build already, etc. And it all disappears when I use these changes. |
Nice! A comment from the cabal gurus would be much appreciated to move this
patch forward!
Merijn Verstraaten <[email protected]> schrieb am Do., 12. Apr.
2018, 14:23:
… Incidentally, this PR seems to fix a *truckload* of issues with
new-build's dependency tracking for me. I've been struggling to figure out
what was going on with new-repl and new-build being weird about whether
stuff had build already, etc. And it all disappears when I use these
changes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5226 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AByiiYU5E4o5b2Qj77xbS4NVqrFmxLKWks5tn0dKgaJpZM4S0s6W>
.
|
@23Skidoo ping |
@ezyang did you take into account #5226 (comment) ? EDIT: ...you didn't, see #5260 |
Currently settings
documentation: true
enables documentationgeneration via haddock for your whole package, including tests and benchmarks.
However, there are additional flags to control generation of
documentation for these "second class" documentation targets, which are
currently not honored at the cabal-install side of things. Namely,
tests
,benchmarks
,executables
, etc. provided under thehaddock
section in your$CABAL_HOME/config
.This patch adds a more sensible approach to documentation generation
via haddock. The new behaviour works like this:
Setting
documentation: true
or passing--enable-documentation
to cabal-install enables documentationfor any component in the build plan honoring the respective
flags for "second class" doc targets from configuration
or CLI.
Invoking new-haddock with a target selector will make sure
the respective flags for "second class" doc targets are set
correctly. E.g.
Will generate documentation for the test suite of your package
even if you have
tests: false
in your haddock configuration.Please include the following checklist in your PR:
[ci skip]
is used to avoid triggering the build bots.Please also shortly describe how you tested your change. Bonus points for added tests!