Simplify docs generation

j3parker commented 4 years ago

The first commit has the interesting changes, the next commit is just fiddling with the labels.

jrbeverly commented 4 years ago

I'm not sure what this is simplifying as it just seems to remove more granular component of the bzl_srcs pattern. If we have just a top level bzl_srcs, then we can only perform rules on all *.bzl files.

For something like stardoc, this works fine as it operates on the whole tree, but if we wish to work more granular, we would need to rollback these changes selectively.

j3parker commented 4 years ago

Yeah, I can't think of why we'd want that granularity though. Did you have a use-case in mind?

Having so many targets and packages is confusing - that's what I'm simplifying :) I noticed this when I went to add docs to rules_brotli.

jrbeverly commented 4 years ago

I don't have an exact use-case at the moment, as I've just started poking around the idea of having //tools that allows us to perform modifications / generations of the source. So I'll just perform a dump of some things I have been thinking in that area:

Exposing our C# Starlark AST library as a rule a la @d2l_rules_csharp//libs:CSharp.Skylark
Running buildifier as a bazel target
Running clang-format as a bazel target
Generating the framework build files using our internal tool (bazel run //tools/frameworks:generator
Generating the provider.bzl from a set of yml files declaring each of the frameworks
Bazel targets within the rules (non-public) that bundle up parts of the rules (zip/etc)
Windows specific test runs (e.g. net472 runs)
Exposing internal rules of rules_csharp to related packages (e.g. //tools, `//lib, //docs)
Exposing the wrappers / etc allowing for testing externally (e.g. run bat tests on a bash wrapper file)

The current model is a bit of 'future-planning' for 'what-if' futures, but since the overhead of adding new packages involves changing a bunch of file references, I'd prefer to keep it with this pattern

note: the use case for bazel_tools is a bit different from us, as we have a public API, and they have an open API.

j3parker commented 4 years ago

Ok, then let's keep it simple for now. YAGNI etc.

I'm not sure how all these extra packages and targets would help with any of those ideas.

j3parker commented 4 years ago

I'm merging this because I want to avoid a merge conflict.

Brightspace / rules_csharp

Simplify docs generation #118