There are about 12 targets currently, that disable the layering check. This is because they include headers that are not exported (i.e. in hdrs = [...]) by any library but are private headers in srcs = [...].
(Note, there might also be other libraries that don't have the layering check disabled, but still accidentally compile due to wide use of includes = [...]; but let's focus on the layering check disabled targets first).
This should be fixed. Ideal would be to break out the targets that do have some private headers that are useful for other internal targets (the majority of these exceptions are currently on tests) break out into a separate library that is private in the package and allows visibility to the other internal targets that need it (if it is in the same package, nothing to do; if it is a test in a separate sub-directory: add visibility pattern to there (something like visibility = ["//src/web/test:__pkg__"].
To get a list of the affected targets:
$(etc/get-bant-path.sh) print ... -g "-layering_check"
Some of these targets are somewhat 'entangled' unfortunately, so often it is not possible to 'simple' break out a small portion, as they include yet other things. So the result might be breaking up things into more, smaller libraries, which will the code health by a lot, so it is very worthwhile.
I've done a bunch of these cleanups already but due to the entanglement and limited project insight, I can't always tell what would be good dependency boundaries to split out libraries. Passing to @maliberty to triage.
There are about 12 targets currently, that disable the layering check. This is because they include headers that are not exported (i.e. in
hdrs = [...]) by any library but are private headers insrcs = [...].(Note, there might also be other libraries that don't have the layering check disabled, but still accidentally compile due to wide use of
includes = [...]; but let's focus on the layering check disabled targets first).This should be fixed. Ideal would be to break out the targets that do have some private headers that are useful for other internal targets (the majority of these exceptions are currently on tests) break out into a separate library that is private in the package and allows visibility to the other internal targets that need it (if it is in the same package, nothing to do; if it is a test in a separate sub-directory: add visibility pattern to there (something like
visibility = ["//src/web/test:__pkg__"].To get a list of the affected targets:
Some of these targets are somewhat 'entangled' unfortunately, so often it is not possible to 'simple' break out a small portion, as they include yet other things. So the result might be breaking up things into more, smaller libraries, which will the code health by a lot, so it is very worthwhile.
I've done a bunch of these cleanups already but due to the entanglement and limited project insight, I can't always tell what would be good dependency boundaries to split out libraries. Passing to @maliberty to triage.