Description of the feature request:

We've been working on something called PROJECT.scl. This is a source of truth for project information, checked in version control next to build targets. It can conceptually contain various kinds of information. But we're focusing now on declaring "correct" build flags for a project, or auto-applying default flags on a per-project or even per-target basis..

For example:

1. $ bazel build //myproject:foo
2. bazel walks up //myproject's package path and finds myproject/PROJECT.scl
3. myproject/PROJECT.scl declares that all targets in //myproject should by defualt set -c opt --//myproject:custom_flag=foo
4. So $ bazel build //myproject:foo automatically adds --c opt --//myproject:custom_flag=foo

Or:

1. myproject/PROJECT.scl defines --scl_config=some_supported_config which sets another set of build flags
2. $ bazel build //myproject:foo --scl_config=some_supported_config automatically sets those flags
3. This is similar to bazerlc / --config with the important distinction that this is project-scoped: //myproject:foo can declare completely independent settings vs //yourproject:bar. The right settings automatically apply to the right target regardless of who's building on what machine from what repo. bazelrc, by contrast, depends heavily on the user and the main repo, and basically doesn't map well to project granularity.

This is intended to better support the idea that $ bazel build //foo "just works", regardless of where or how or from whom it's invoked. This opens up all kinds of interesting possibilities like easily reproducing CI at the command line, more portable CI because setup is Bazel-internal and therefore detached from whatever system invokes it, library maintainers can build projects that depend on them, less need for "how to build" project docs, better remote cache hit rates, cheaper builds, more cache pre-warming. and easier refactoring.

It also supports possibilities like memory-efficient incremental builds and faster / more memory-efficient project feature flags

BazelCon 2024 showed interest in these ideas. I promised to follow up and support discussion. This bug report is a start but there are a lot of important details we need to make sense of. Like how (or if) this fits with REPO.bazel or MODULE.bazel, which flags this can and can't apply to, and new build paradigms we could imagine like $ bazel build ///foo%entire_ci_project.

I'll expand this all out in a proper Github discussion.

Which category does this issue belong to?

No response

What underlying problem are you trying to solve with this feature?

$ bazel build //foo "just works" without having to know which flags to set.

Even more portable and reproducible builds.

Which operating system are you running Bazel on?

n/a

What is the output of bazel info release?

n/a

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

n/a

What's the output of git remote get-url origin; git rev-parse HEAD ?

n/a

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

history of recent commits