Customizing the name of configuration files Bazel uses

[lberki]

Bazel currently hard-codes the name of the configuration files it reads: BUILD.bazel, WORKSPACE.bazel, MODULE.bazel, etc.

Every once a while, we run into problems with this. The most common use case is that one wants to vendor a project that already builds with Bazel, but the existing configuration files don't work for some reason. Reasons include:

• The code is vendored in a subdirectory (where else?) and labels crossing package boundaries cannot be relative. Thus, if the project consists of more than one Bazel package, BUILD.bazel files need to be heavily rewritten
• The vendoring project might have different ideas as to how the vendored project should be compiled which makes the existing configuration files useless
• Sometimes one wants to e.g. glob over a whole vendored project, but that doesn't work if the project contains BUILD.bazel / WORKSPACE.bazel file because glob stops there.

so it occurs to me every once in a while that maybe we should teach Bazel to read configuration files with different names. It's not obvious how that should happen (you can't put it in WORKSPACE.bazel because the name of that file would depend on the value of this knob).

I do realize that this is quite a bit of rope and I haven't even started exploring what systems other than Bazel would need to be aware of this knob (e.g. Buildifier), but this discussion is a good place to collect opinions for and against.

The canonical workaround is to build a wrapper around Bazel that creates a symlink forest that "edits out" undesired BUILD.bazel files from the source tree and call Bazel with that symlink forest as the workspace. It's as ugly as it sounds, but so far, everyone who went this route was satisfied with the results, as surprising as it is.

[Wyverald]

Unclear to me how allowing customizing those file names solves the vendoring problem. Are you proposing that the main project use BUILD.my / WORKSPACE.my etc, so that BUILD.bazel in vendored projects are treated as normal files?

IMO that's much worse than just editing your vendored files to rename all BUILD.bazel to something else.

[lberki]

Yep, that's the idea: that the outer project would use file names like BUILD.outer whereas the inner project would use whatever file names they use.

I do realize that renaming files during vendoring is not a very complicated operation, but e.g. Android is not very enthusiastic about that option.

[brentleyjones]

Btw, if you are replying to @Wyverald, you can/should use the "Write a reply" section to do so. This "reply" might get out of order otherwise (as it's seen as an independent reply/thread to your original post ).

[Wyverald]

Android is not very enthusiastic about that option.

any reason in particular?

[lberki]

My understanding is that they want to vendor projects verbatim, which precludes renaming files. Whether it's a good thing to want, I don't know.

[mattyclarkson]

The most common use case is that one wants to vendor a project that already builds with Bazel, but the existing configuration files don't work for some reason.

The de-facto thing is to patch the vendored project.

Usually, that is to take the released project and inject the necessary patches on top of it.

http_archive can apply the patches.

We do similar through bzlmod to patch projects that already build with Bazel to conform to our Bazel toolchain setup.

This is how Linux distributions "vendor" the upstream projects into their package repositories.

I'm unclear on how this is any different to using a symlink forest layer over the build files, you're still doing the patching work just in a different way.

to collect opinions...against.

We'd be against this direction in favour of patching vendored projects. Unless we're missing why patching is not applicable here.

[katre]

I wrote the original support for BUILD.bazel back when I joined the team (geez, that was forever ago). I have probably lost the original documentation, but one alternative we considered was to add a flag that controlled the build file name: instead of the previous version (only support BUILD files) or the current (support a mix of both BUILD and BUILD.bazel files), this would have lead to a project-by-project decision, similar to what you suggest.

The biggest problem we identified, and the main reason we went with the current (much more complex) system, was handling external repositories: if my project only uses BUILD.bazel, and I want to import a project that uses BUILD, either Bazel needs a complex system to change the value as we cross that external repository boundary, or users need to patch repositories to change the build file name.

This isn't quite the same as your proposal, but is very similar, so I suspect that the same reasons weigh against it.