Open guibou opened 5 years ago
This sounds like two orthogonal tickets (with separate goals) to me. Regarding the first one, I assume we by now have a clear idea of use cases? We can make do with the current API and the limitations of Bazel just fine if rather than the ability to pass arbitrary flags to Haddock, all we need is a few enums that turn on or off specific Haddock features.
@mboes some haddock command line parameters are not just boolean switchs. For example --css
, --hide
, --show
, ...
I know that. Point is, is this a theoretical concern or a real one? We may have to change the API down the line, but adding enums now can go a long way for most people.
It is a theoretical concern.
If the need to pass arbitrary parameters arise, a possible (though annoying) way is to not expose the aspect, but a macro that given a list of flags builds an aspect. Something like:
def make_haskell_doc_aspect(haddock_flags):
return aspect(
_haskell_doc_aspect_impl(haddock_flags),
attrs = { ... },
)
def make_haskell_doc(haddock_flags=[]):
custom_haddock_aspect = make_haskell_doc_aspect(haddock_flags)
rule(
_haskell_doc_rule_impl,
attrs = {
"deps": attr.laebl_list(
aspects = [custom_haddock_aspect],
...
}
)
That way the user can call make_haskell_doc
in a .bzl
file to create a variant of the haskell_doc
rule with the right flags. That's a big detour for a simple thing, but afaict that would work
I actually would like to pass flags too (if anything -v
). What's the issue with letting the user pass its own flags ?
This is a reopen of #425 to enhance
haskell_doc
in two ways:haskell_doc
should accept a custom list ofhaddock_flags
. For now,haddock_flags
can only be overridden inhaskell_toolchain
.haskell_doc
should be composable so thathaskell_doc
can take other documentation rule asdeps
argument.Custom list of haddock flags for haskell toolchain is a complex implementation (see #425) for the discussion.