LLVM repo layout support

[keith]

I'm interested in trying this tool out on the llvm repo, more for managing deps than creating new libraries, but that project uses this source layout:

<dir>/lib/<name>/**/*.{cpp,h}
<dir>/include/<name>/**/*.h

Because of this we place the BUILD files in <dir>/BUILD.bazel and then they have many cc_library targets in them which reference files from both the lib and include subdir (small example lib here.

I tried a few variants of gazelle:cc_group subdirectory but it doesn't look like that does what I need with the single mono-BUILD file. Am I missing the configuration for something like this layout? Otherwise is this something that would be reasonable to support?

[jayconrod]

This is not something that would work with gazelle:cc_group subdirectory. I think we'll need to add a new mode to support this.

The way you describe this makes me think we should allow the user to set a pattern for sources, headers, tests, and so on, and the pattern could include the library name. If the pattern doesn't include the library name, then it's equivalent to subdirectory mode (one library per package).

Just a vague sketch:

# gazelle:cc_group pattern
# gazelle:cc_group_pattern_srcs lib/$name/**
# gazelle:cc_group_pattern_hdrs include/$name/**

[keith]

yea that's why i was trying to find with the combo of the other attributes. i think something like that could definitely work.

ofc llvm lays out tests in an entirely different way, but likely there a single target per file would be appropriate like the unit grouping today.

seems to me that it's probably likely that other folks have non-standard layouts like this too so i think having more customizability for that would be great

[jayconrod]

How does LLVM lay out tests? Is there any way we could reasonably set up a few patterns to translate their tests into cc_test targets?

[keith]

typically 1 target per source file, and i think having a BUILD file per directory for that would be fine. today since they were handwritten it looks like the original author hoisted the BUILD file up in that case tho:

https://github.com/llvm/llvm-project/blob/bb6d2bea6495b044a0773598916eba801f8d38fc/utils/bazel/llvm-project-overlay/llvm/unittests/BUILD.bazel#L53-L83

(there's an interesting detail in that the bazel support in this repo actually doesn't live beside the source files and is overlayed manually with a repo rule 😬)

[jayconrod]

There are a lot of globs here: some tests are single files, others are whole directories. It would be hard to generate something like this, but if test-per-directory works, that might be viable with light restructuring. It sounds like we also might need to decouple the library grouping mode from the test grouping mode.

(there's an interesting detail in that the bazel support in this repo actually doesn't live beside the source files and is overlayed manually with a repo rule 😬)

I guess that's because most of the devs don't use Bazel and don't want build files in the way? That certainly adds complication.

[keith]

There are a lot of globs here: some tests are single files, others are whole directories.

yea i think some of that is incidental. but i guess there is a risk that some have to be that way in which case those specific targets might have to be manually managed?

I guess that's because most of the devs don't use Bazel and don't want build files in the way? That certainly adds complication.

yea that was the original thought, to reduce confusion about what the default build system was (cmake). fwiw i was mostly using this as a straw man repo layout because our repo heavily uses llvm and so it inherited this directory structure, but we ofc put our BUILD files inline.