Adin Ćebić (Unofficial) / Adin Ćebić (Unofficial) is on Nostr

Unofficial automated RSS/Atom links from the source Adin Ćebić, covering Detailed Swift/Bazel engineering tutorials and implementation notes. Original creators are credited at the source; follow original links. Zaps support the independent feed operator, not the source creators.

Last Notes

2026-11-02 02:37:46 GMT

Validating Bazel Rule Attributes
Oftentimes, it is necessary to validate rule attributes to prevent misuse of a rule. While attributes can be validated as part of the main rule implementation function, there is perhaps a better way to do it.
Rule initializer
This is yet another lesser-known feature of Bazel, where we can declare an initializer function that runs when a rule is instantiated. In my opinion, this is the ideal place to validate inputs.
Take this fictitious rule, where we want to make sure that it only accepts certain modes:
def _init(name, mode = "safe", **kwargs):
if mode not in ["safe", "fast"]:
fail("mode must be 'safe' or 'fast'; got %r" % mode)
return {"mode": mode}
def _impl(ctx):
out = ctx.actions.declare_file(ctx.label.name + ".txt")
ctx.actions.write(out, ctx.attr.mode + "\n")
return [DefaultInfo(files = depset([out]))]
validated_file = rule(
implementation = _impl,
initializer = _init,
attrs = {
"mode": attr.string(),
},
)
Passing an unsupported mode will result in a failure during the loading phase, before Bazel even gets to analyzing the target.
This is an important distinction compared to validating attributes in the rule implementation function, which runs during the analysis phase. With an initializer, invalid inputs are caught earlier, when the rule is instantiated in a BUILD file.
Another interesting detail is that initializers can also modify attribute values by returning a dictionary containing the attributes to override. Attributes that are not returned remain unchanged. In our example, we simply return the validated mode value.
Notice that we also define the default value of mode in the initializer rather than in attr.string(). Initializers run before attribute defaults are applied, so a default specified in the initializer takes precedence. The **kwargs parameter allows us to ignore other public attributes that we don’t need to validate.
Experimental status
The initializer parameter is still marked as experimental in Bazel’s API documentation. However, this designation is outdated.
The --experimental_rule_extension_api flag has been enabled by default since Bazel 8, meaning the feature is no longer restricted to allowlisted users by default. Fabian, a trusted Bazel contributor, has also opened a PR to remove the outdated experimental designation from the documentation.
So despite what the current documentation suggests, feel free to use it.
Conclusion
While there are a couple of ways to validate inputs in a Bazel rule, I think this one deserves to be used more widely since it feels like the right tool for the job.
https://adincebic.com/2026/11/01/validating-bazel-rule-attributes.html
#rss #feeds #linksharing #qwibbit

2026-10-26 02:37:21 GMT

What Bazel Thinks Has Changed
Very often, engineers I support ask me how they can inspect what Bazel thinks has changed between builds. While it’s true that they could generate execution logs and compare them, they often don’t have those enabled, and diffing the logs can be tricky given how large they can get.
Yes, there’s the BuildBuddy CLI, which can help with that, but there’s another way to peek into Bazel’s state and see which files Bazel detected as changed when deciding what needs to be re-evaluated.
Enter DiffAwareness
This is a neat trick for inspecting Bazel’s server log to see what changes Bazel detected.
After running a build, we can use grep, rg, or any other tool to inspect the log.
For example:
bazel build //:app
Now, let’s say the build has finished. Whether Bazel actually re-ran any actions (or invoked the compiler) is a different question. We can inspect which file changes Bazel detected by running:
rg 'DiffAwareness found' "$(bazel info server_log)"
This will show the changes Bazel detected since the previous evaluation, with the log listing at most 10 individual changed paths per diff-awareness event.
Here, we’re simply using rg to search Bazel’s server log. Nothing fancy.
One important distinction: these are files Bazel detected as changed, not necessarily files that caused an action to re-run. Bazel may still determine that no actions need to be executed.
Conclusion
This isn’t something I use all that much, and to be frank, I don’t find it particularly useful day to day. But it’s nice to have in the toolbox when debugging builds, investigating unexpected rebuilds, or even debugging Bazel itself.
https://adincebic.com/2026/10/25/what-bazel-thinks-has-changed.html
#bazelthinks #whetherbazel
#rss #feeds #linksharing #qwibbit

2026-10-19 02:47:14 GMT

BazelCon 2026: My Notes and Observations
I always find BazelCon to be an exceptional experience, and this year was no exception. From the things I learned by randomly talking to people, to meeting familiar faces and learning from the talks and BOF sessions, it is simply an incredible experience.
Today I want to go over some things I observed and what I am looking forward to in Bazel 10.
AI is everywhere
Nowadays, when we are all using AI agents every day, I find that using AI is becoming just like using any other tool. There was no talk about doomsday scenarios, but rather encouragement to use AI even more.
On more than one occasion, people would say “point your agent at the documentation” instead of reading the documentation yourself.
Also, EngFlow’s report on how much people are using AI was eye-opening. It’s not like I didn’t expect it, but seeing the numbers really puts things into perspective.
IDEs as we know them are going away
It seems that nobody is focusing on IDEs as much as we did before. For example, we’ve seen the use of rules_xcodeproj going down in some large organizations in favor of more lightweight alternatives like VS Code.
I feel like the next opportunity for IDEs is a more integrated code review experience and better code navigation.
Investing heavily in better autocomplete seems wasteful since fewer people are relying on it as their primary way of writing code. Sure, it is always good to have it in some shape or form, but I don’t expect it to be the main focus of IDE improvements in the coming years.
Bazel 10
Bazel 10 continues the effort of moving language-specific functionality out of the core and into Starlark extensions.
There are also a lot of welcome performance improvements, some of which are being accelerated by the use of AI.
Project Skymetal
This is an effort to replace parts of Bazel’s Java implementation with native code, currently focusing on Rust.
It is going to take some time, as the Bazel team won’t simply replace all Java with Rust overnight. Instead, the plan is to migrate component by component, using JNI to bridge Java and Rust.
Early results are promising, but I expect we’ll get a better picture of how it plays out once more of the codebase has been migrated.
Skycache
Skycache is basically an attempt to remotely cache Bazel’s analysis state, which is becoming more expensive to compute over time, especially in larger monorepos.
This effort started last year, and by the looks of it, it is gaining more traction. In fact, Google is already experimenting with an early implementation internally, though their results do not automatically translate to analysis caching for everybody, as Google relies on infrastructure such as its cloud-based filesystem.
Stripping native flags
Rulesets like those for Apple platforms have historically relied on Bazel’s native flags for CPU selection and various other things.
The effort to remove these language-specific flags from Bazel core is continuing, with equivalents being provided through Starlark-based configuration, including the apple_support module.
Talks and other relevant information
Snapshotting Bazel server state
This is an interesting approach to snapshotting the entire Bazel server state so that we don’t have to pay the analysis cost every time.
Of course, this can be fragile, but I believe it can be useful if done carefully.
Hermetic LLVM
Hermetic LLVM got a lot of attention during this BazelCon, and I think it is well deserved.
David and Corentin did an amazing job of providing a fully hermetic C/C++ toolchain, which has always been a challenge in Bazel.
Hopefully, this finally puts the issue to rest.
rules_rs
Similar to Hermetic LLVM, rules_rs is getting a lot of well-deserved attention due to its fast Cargo dependency resolution and strong emphasis on hermeticity.
Sandbox on macOS
Of course, it is well known that Bazel sandboxing on macOS is not as performant as on Linux, so folks over at Aspect have been working on providing a way to plug in a custom sandboxing binary.
Hopefully, someone finds a way to finally make sandboxing on macOS as fast as it is on Linux.
Any to Bazel
This is a quick note on any2bazel, a tool developed by EngFlow that aims to help humans and AI agents migrate projects to Bazel.
It uses a deterministic approach to compare what the original build system actually compiles and links against what Bazel produces. This helps guide agents toward a correct migration, because simply getting a green build is not enough.
Apple Birds of a Feather
The last time we had an Apple BOF was in Mountain View, California.
This time, there was a lot of discussion about excessive disk usage in tests when statically linking dependencies. The quick fix is to use dynamic frameworks, but that comes at the cost of slower startup times and potentially other issues.
Another popular topic was Linux-to-macOS remote build execution (RBE), where Linux is used as the CI runner and macOS machines as remote executors. This effectively allows us to initiate builds from Linux while executing Apple-specific build actions on macOS.
There was also a discussion about building Apple targets directly on Linux, but the potential licensing issues make this approach unappealing to large organizations.
Of course, the Apple BOF would not be complete without mentioning Swift explicit modules support in rules_swift. Thank you, Keith, for doing the work!
Conclusion
There you have it. Yet another incredible BazelCon behind us, and I am already looking forward to the next one.
P.S. I know I haven’t covered a lot of ground here, but these are just my quick notes and observations.
https://adincebic.com/2026/10/18/bazelcon-my-notes-and-observations.html
#bazel #code #java #rust #ides #google #skycache
#rss #feeds #linksharing #qwibbit

2026-10-16 02:39:10 GMT

Fine-Grained Swift Warning Control with Bazel Features
Ever since Swift gained the ability to control warnings via diagnostic groups in SE-0443, we’ve been able to promote specific diagnostic groups to errors.
However, passing these flags via copts on swift_library targets isn’t always convenient. To apply them globally, we’d either need to modify every swift_library target, pass them via the command line, configure them in .bazelrc, or use Bazel macros to apply them automatically. All of these approaches have their downsides, such as accidentally applying the flags to external repositories, introducing additional complexity through macros, or making it difficult to opt out for specific targets.
In the past, I’ve written about Bazel’s features mechanism, as well as how to suppress warnings in external repositories.
Bazel feature-based approach
In rules_swift 4.2.0, we added a way to control these warnings using Bazel’s features mechanism in #1960.
Simply build a target while passing --features, like so:
bazel build //... --features=swift.werror.DeprecatedDeclaration
And all warnings belonging to the DeprecatedDeclaration diagnostic group will be reported as compiler errors.
This approach is extremely flexible, as it allows per-target control via the features attribute, repository-wide configuration via REPO.bazel, which only applies to the current Bazel repository, and, of course, configuration via the command line or .bazelrc.
Furthermore, we can take advantage of Bazel’s feature negation mechanism by prefixing feature names with -, allowing us to opt out of specific features when needed.
For example, if we’ve enabled swift.werror.DeprecatedDeclaration globally but want to opt out for a specific target, we can simply negate the feature in its features attribute:
swift_library(
name = "legacy_library",
srcs = ["Legacy.swift"],
features = ["-swift.werror.DeprecatedDeclaration"],
)
This way, deprecated declaration warnings will remain warnings for legacy_library, while still being treated as errors for the rest of the project.
Conclusion
There we have it: a simple and clean way to control Swift warnings with Bazel.
P.S. I wish Swift would give us a way to suppress warnings per diagnostic group. If that ever comes to fruition, I’ll be the first to add a feature-based approach to rules_swift.
https://adincebic.com/2026/10/11/finegrained-swift-warning-control-with.html