Skip to content
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

allow passing command line flags to haddock #425

Closed
ghorn opened this issue Aug 30, 2018 · 3 comments
Closed

allow passing command line flags to haddock #425

ghorn opened this issue Aug 30, 2018 · 3 comments
Assignees
Labels
P2 major: an upcoming release type: feature request

Comments

@ghorn
Copy link
Contributor

ghorn commented Aug 30, 2018

I would like to be able to pass --ignore-all-exports to haddock in order to display haddock comments on internal functions. Could a field be added to haskell_doc for passing additional flags? Or maybe just a boolean field for this flag if you're afraid of users trying to unsafely override flags.

@ghorn
Copy link
Contributor Author

ghorn commented Aug 30, 2018

from https://www.haskell.org/haddock/doc/html/invoking.html:

--ignore-all-exports
Causes Haddock to behave as if every module has the ignore-exports attribute (Section 3.7, “Module Attributes”). This might be useful for generating implementation documentation rather than interface documentation, for example.

@guibou
Copy link
Contributor

guibou commented Nov 20, 2018

A bit of followup on that one.

This is a real pain. It is possible to set attributes to a rule which will be passed to the aspects (used by haskell_doc). However these attributes are limited: they must be a string from a finite list of possible values:

Public aspect attributes are of type string and are called parameters. Parameters must have avalues attribute specified on them. In this case we have a parameter called extension that is allowed to have ‘*’, ‘h’, or ‘cc’ as a value.

(from https://docs.bazel.build/versions/master/skylark/aspects.html)

That's by design in bazel.

PR #444 was a PR with a proof of concept of a limited set of arguments. It was closed because the solution was a HACK.

@mboes
Copy link
Member

mboes commented Nov 21, 2018

Yet another reason to change the design in the following way?

$ bazel build //some/package:target@doc

i.e. use implicit targets for API documentation, like we currently do for REPL's?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 major: an upcoming release type: feature request
Projects
None yet
Development

No branches or pull requests

3 participants