BazelInject is an experiment to add advanced capabilities to the Bazel ecosystem via external APIs. Today you can extend Bazel with Starlark, but said capabilities aren't possible to achieve via Starlark. Upstreaming the rules to Bazel would make it too flexible per proposal rejections, so enable it via external APIs. This is the alternative to doing it in ad-hoc forks of Bazel and promotes reuse.
Bazel inject provides low level Jar injection atm
# Build from source to bazel-inject/BazelInject.jar
git clone https://github.com/bazel-ios/bazelinject.git
make
# First, build your rules into a Jar file:
# e.g: cd /path/to/bazel
# bazel build src/main/java/com/google/devtools/build/lib/bazel:main
# Then, BazelInject injects /path/to/my.jar into Bazel
--host_jvm_args -Dbazel.inject=/path/to/bazel/bazel-bin/src/main/java/com/google/devtools/build/lib/bazel/libmain.jar
--host_jvm_args -jar
--host_jvm_args /path/to/bazelinject/bazel-inject/BazelInject.jar
Note: if you're developing BazelInject - use a sha in the path - see tools/bazel for usage
Today you can add a macro or rule in starlark, these APIs enable your starlark rules to interface with Bazel internals how you see fit. think post analysis actions and other concepts you want but won't go into Bazel.
This is a new set of APIs with similar ideas as the Starlark API, but enables an
interface to primitives like Action, RuleDefinition, and Artifact to
unlock advanced capabilities. The gist is you might include jvm features in
existing Starklark rules e.g. alongside starlark_library. For instance, your
own "build" APIs like cc_common or your own rules like objc_library based on
RuleDefinition.
Note: while this may use similar concepts or directly use primitives like RuleDefinition, or Spawn, - it
doesn't mean we'd make it intra-process or operate in the same way.
A new startup Bazel option -Dbazel.module= that loads a BlazeModule or
similar at the specified path: e.g.
-Dbazel.module=com.my.bazel.module:/path/to/module.jar
BlazeModule is low level way to add custom spawn strategies, rules, and more.
This API could start with a subset of BlazeModule
Flexibility - there are key features community build system engineers would like to add. The capabilites we'll enable here aren't suited for Bazel's core codebase, release workflow, or PR review process.
Maintainability - interfacing with native Bazel providers, rules, and spawns is piviotal to using it at first, but for more advanced ecosystems implicates maintainer thrash and has severe limitations.
Reuse - developing a set of advanced capabilities we can depend on in
rules_ios - and can be integrated by RBE vendors - or others already creating
their own builds. This might mean restricting to the Java rules API.
Finally, some of the rules will hinge on assumptions about actions end to end
e.g. action refinement based on how we build an iOS app with rules_ios. I'd
also want to provide optional features that call native functionaity directly in
rules_ios e.g. flipping on optimizations backed by JVM bytecode and these
APIs`
Powerful APIs and/or adding rules via BlazeModule, jar injection, enable a number of features like:
- Post analysis actions
- Comprehensive integration of rules_ios Virtual frameworks
- Variants of C++ header scanning