Introducing the Pigweed SDK: A modern embedded development suite

Back in 2020, Google announced Pigweed, an open-source collection of embedded libraries to enable a faster and more reliable development experience for 32-bit microcontrollers. Since then, Pigweed’s extensive collection of middleware libraries has continuously evolved and now includes RTOS abstractions and a powerful RPC interface. These components have shipped in millions of devices, including Google’s own Pixel suite of devices, Nest thermostats, DeepMind robots, as well as satellites and autonomous aerial drones.

Today, we introduce the first developer preview of the Pigweed SDK, making it even easier to leverage Pigweed’s libraries to develop, debug, test, and deploy embedded C++ applications. Using the included sample applications and comprehensive tutorial, you can easily get started prototyping simple programs and build up to more complex applications that leverage advanced Pigweed functionalities. Pigweed’s modern and modular approach makes it easy to design applications with significantly reduced debugging and maintenance overhead, thus making it a perfect choice for medium to large product teams.

We are also thrilled to contribute to the Raspberry Pi Pico 2 and RP2350 launch, providing official support in Pigweed for RP2350 and its predecessor, the RP2040. Building on the success of the Pico 1 and RP2040, the Pico 2 introduces the RP2350 microcontroller, bringing more performance and an exciting set of new capabilities in a much lower power profile. We’ve worked closely with the Raspberry Pi team to not only provide a great experience on Pigweed, but also upstreamed a new Bazel-based build system for Raspberry Pi’s own Pico SDK.

Raspberry Pi Pico 2 (RP2350) with Enviro+ pack hat.

What's in the SDK

The Pigweed SDK aims to be the best way to develop for the Pico family of devices. The SDK includes the Sense showcase project, which demonstrates a lot of our vision for the future of sustainable, robust, and rapid embedded system development, such as:

• Hermetic building, flashing, testing, and cross-platform toolchain integration through Bazel.

• Fully open-source Clang/LLVM toolchain for embedded that includes a compiler, linker, and C/C++ libraries with modern performance, features, and standards compliance

• Efficient and robust device communication over RPC

• An interactive REPL for viewing device logs and sending commands via command-line and web interfaces

• Visual Studio Code integration with full C++ code intelligence

• GitHub Actions support for continuous building and testing

• Access to pico-sdk APIs when you need to drop down to hardware-specific functionality

Utilize the Pigweed CLI console to communicate with your device through interactive Remote Procedure Calls (RPCs).

By building your project with the Pigweed SDK (using the Sense showcase as your guide), you can start on readily available hardware like the Pico 1 or 2 today. Then when you’re ready to start prototyping your own custom hardware, you can target your Pigweed SDK project to your custom hardware without the need for a major rewrite.

Try Sense now

Bazel for embedded

Pigweed is all-in on Bazel for embedded development. We believe Bazel has great potential to improve the productivity (and mental wellbeing) of embedded development teams. We made the "all-in" decision last September and the Raspberry Pi collaboration was a great motivator to really flesh out our Bazel strategy:

• We contributed to an entirely new Bazel-based build for the Pico SDK to make it easy for the RP2 ecosystem to use Bazel and demonstrate how Bazel takes care of complex toolchains and dependencies for you.

• The new Sense showcase demonstrates Bazel-based building, testing, and flashing.

• Our GitHub Actions guide shows you how to build and test your Bazel-based repo when pull requests are opened, updated, or merged.

Head over to Bazel's launch blog post to learn more about the benefits of Bazel for embedded.

Clang/LLVM for embedded

Pigweed SDK fully leverages the modern Clang/LLVM toolchain. We are especially excited to include LLVM libc, a fully compliant libc implementation that can easily be decomposed and scaled down for smaller systems. The team spent many months developing and contributing patches to the upstream project. Their collaboration with teams across Google and the upstream LLVM team was instrumental in making this new version of libc available for embedded use cases.

The sample applications, Pigweed modules, host-side unit tests, and showcase examples already use Clang, LLD, LLVM libc and libc++. Thus, developers can take advantage of Clang’s diagnostics and large tooling ecosystem, LLD’s fast linking times, and modern C and C++ standard library implementations which support features such as Thread Safety Analysis and Hardening.

IDE integration

With full Visual Studio Code support through pw_ide, you can build and test the Sense showcase from the comfort of a modern IDE and extend the IDE integration to meet your needs. Full target-aware code intelligence makes the experience smooth even for complicated embedded products. Automatic linting, formatting, and code quality analysis integrations are coming soon.

Parallel on-device testing with PicoPico

As you would expect from a team with the mission to make embedded development more sustainable, robust, and rapid for large teams, we are of course obsessed with testing. We have hundreds of on-device unit tests running all the time on Picos. The existing options were a bit slow so we whipped up PicoPico in a week (literally) to make it easier to run all these tests in parallel.

One “PicoPico” node for running parallel on-device tests

RP2 support

The goal behind our extensive catalog of modules is to make it easy to fully leverage C++ in your embedded system codebases. We aim to provide sensible, reusable, hardware-agnostic abstractions that you can build entire systems on top of. Most of our modules work with any hardware, and we have RP2 drivers for I2C, SPI, GPIO, exception handling, and chrono. When Pigweed's modules don't meet your needs, you can still fallback to using pico-sdk APIs directly.

Get started

Clone our Sense showcase repo and follow along with our tutorial. The showcase is a suitable starting point for learning what a fully featured embedded system built on top of the Pigweed SDK looks like.

What’s next

The Pigweed team will continue to have regular and on-going preview releases, with new features, bug fixes, and improvements based on your feedback. The team is working on a comms stack for all your end-to-end networking needs, factory-at-your-desk scripting, and much, much more. Stay tuned on the Pigweed blog for updates!

Learn more

Questions? Feedback? Talk to us on Discord or email us at [email protected].

We have a Pigweed Live session scheduled on August 26th, 13:00 PST where the Pigweed team will talk more about the Pigweed SDK and answer any questions you have. Join [email protected] to get an invite to the meetings.

Acknowledgements

We are profoundly grateful for our passionate community of customers, partners, and contributors. We honor all the time and energy you've given us over the years. Thank you!

By Amit Uttamchandani – Product Manager, Keir Mierle – Software Engineer, and the Pigweed team.

A look back at BazelCon '23 and the launch of Bazel 7

In October ‘23, the Google Bazel team hosted the 7th annual BazelCon, a gathering for the Bazel community and broader Build ecosystem. We welcomed enterprise users and program partners, companies building businesses on top of Bazel, as well as enthusiasts curious to learn more about this space. This year, BazelCon made its debut outside North America and was hosted in the Google Munich office.

BazelCon recap

The Bazel ecosystem is growing. This year, we had over 200 in-person external attendees, over 3K livestream views, and a record number of 120 proposals submitted by the community.

We started the conference with a keynote address by Mícheál Ó Foghlú (Engineering Director at Google), followed by a state-of-the-union address by John Field and Tobias Werth (Engineering Managers at Google).

The Bazel community showcased a series of technical and lightning main-stage talks. To highlight a few:

• BMW shared insights into how they released several “Bazel cars”

• JetBrains^* announced the preview release of their new Bazel plugin for their IDEs

• Booking.com walked through their journey of adopting Bazel, thereby reducing CI time from 22 minutes to under 2 minutes and container image size by 80%

Take a look at published recordings of all of these talks at your own leisure.

In addition to hearing from presenters, conference attendees also had the opportunity to engage with each other in smaller, more interactive forums. Through live Q&A with the Bazel team and several Birds of a Feather sessions on topics ranging from authoring rulesets, to collecting usage data responsibly, to IDE integrations, the Bazel community was able to provide direct feedback to the team and spark productive discussions. Make sure to check out published notes from these sessions.

At BazelCon, we also proudly announced the initial release candidate for Bazel 7, which has since launched.

What’s new in Bazel 7?

Bazel 7 is the latest major release on the long-term support (LTS) track. Many multi-year efforts have landed in this release. For example:

Bzlmod: Bzlmod, Bazel's new modular external dependency management system, is now enabled by default (i.e. --enable_bzlmod defaults to true). If your project doesn't have a MODULE.bazel file, Bazel will create an empty one for you. The old WORKSPACE mechanism will continue to work alongside the new Bzlmod-managed system. Learn more about what’s changed since Bazel 6 and what’s coming up in Bazel 8 and 9.

Build without the Bytes (BwoB): Build without the Bytes for builds using remote execution is now enabled by default (i.e. --remote_download_outputs defaults to toplevel). Bazel will no longer try to download any intermediate outputs from the remote server, but only the outputs of requested top-level targets instead. This significantly improves remote build performance. Learn more about BwoB.

Merged analysis and execution (Skymeld): Project Skymeld aims to improve multi-target build performance by removing the boundary between the analysis and execution phases and allowing targets to be independently executed as soon as their analysis finishes.

Platform-based toolchain resolution for Android and C++: This change helps streamline the toolchain resolution API across all rulesets, obviating the need for language-specific flags. It also removes technical debt by having Android and C++ rules use the same toolchain resolution logic as other rulesets. Full details for Android developers are available in the Android Platforms announcement.

Read the full release notes for Bazel 7.

 

Stay up-to-date with Bazel

We are thankful to everyone who played a role in making BazelCon ‘23 a big success - speakers, contributors, attendees, the planning committee, and more. We look forward to seeing you again next year!

In the meantime, follow along as we work together towards Bazel 8:

• Bazel blog
• GitHub
• Mailing list
• Slack
• X (formerly known as Twitter)

If you have any questions or feedback, or would like to share something you’ve built, reach out to [email protected]. We would love to hear from you!

By the Google Bazel team

^*Copyright © 2023 JetBrains s.r.o. JetBrains and IntelliJ are registered trademarks of JetBrains s.r.o

More voices = More Bazel

Takeaways from the BazelCon DEI lunch panel

In front of a standing-room-only lunch panel, Google’s head of Developer X strategy Minu Puranik asks us, “If there is one thing you want to change [about Bazel’s DEI culture], what would it be and why?”

We’d spent the last hour on three main themes: community culture, fostering trust, and growing our next generation of leaders. Moderated by Minu, our panel brought together a slate of brilliant people from underrepresented groups to give a platform to our experiences and ideas. Together with representatives and allies in the community, we explored methods for building inclusivity and sought a better understanding of the institutional and systemic barriers to increasing diversity.

Culture defines how we act, which informs who feels welcome to contribute. Studies show that diverse contributor backgrounds yield more and better results, so how do we create a culture where everyone feels safe to share, ask questions, and contribute? Helen Altshuler, co-founder and CEO of EngFlow, relayed her experience regarding some best practices:

“Having people that can have your back is important to get past the initial push to submit something and feeling like it’s ok. You don’t need to respond to everything in one go. Last year, Cynthia Coah and I gave a talk on how to make contributions to the Bazel community. Best practices: better beginners’ documentation, classifying GitHub issues as ‘good first issue,’ and having Slack channels where code owners can play a more active role.”

                    - Helen Altshuler, co-founder and CEO of EngFlow

Diving further, we discussed the need to make sure new contributors get positive, actionable feedback to reward them with context and resources, and encourage them to take the risk of contributing to the codebase. This encouragement of new contributors feeds directly into the next generation of technical influencers and leaders. Eva Howe, co-founder and Legal Counsel for Aspect, addressed the current lack of diversity in the community pipeline.

“I’d like to see more trainings like the Bazel Community Day. Trainings serve two purposes:

1. You can blend in, start talking to someone in the background, and form connections.

2. We can give a good first educational experience. It needs to be a welcoming space.”

                     - Eva Howe, Legal Counsel – Aspect Dev

In addition to industry trainings, the audience and panel brought up bootcamps and university classes as rich sources to find and promote diversity, though they cautioned that it takes active, ongoing effort to maintain an environment that diverse candidates are willing to stay in. There are fewer opportunities to take risks as part of a historically excluded group, and the feeling that you have to succeed for everyone who looks like you creates a high-pressure environment that is worse for learning outcomes.

To bypass this pipeline problem, we can recruit promising candidates and sponsor them through getting the necessary experience on the job. Lyra Levin, Bazel’s internal technical writer at Google, spoke to this process of incentivizing and recognizing contributions outside the codebase, as a way to both encourage necessary glue work, and pull people into tech from parallel careers more hospitable to underrepresented candidates. And Sophia Vargas, Program Manager in Google’s OSPO (Open Source Programs Office), also offered insight regarding contributions.

“If someone gives you an introduction to another person, recognize that. Knowing a system of people is work. Knowing where to find answers is work. Saying I’m going to be available and responding to emails is work. If you see a conversation where someone is getting unhelpful pushback, jump in and moderate it. Reward those who contribute by creating a space that can be collaborative and supportive.”

                     - Lyra Levin, Technical Writer

“Create ways to recognize non-code contributions. One example is a markdown file describing other forms of contribution, especially in cases that do not generate activity attached to a name on GitHub.”

                      - Sophia Vargas, Program Manager – Google Open Source Programs Office

An audience member agreed that for the few PRs a positive experience is critical for community trust building: And indeed, open source is all about building trust. So how do we go about building trust? What should we do differently? Radhika Advani, Bazel’s product manager at Google, suggests that the key is to:

“Make some amazing allies. Be kind and engage with empathy. Take your chances—there are lots of good people out there. You have to come from a place of vulnerability.”

                    - Radhika Advani, Bazel Product Manager

Vargas also added some ideas for how to be an “amazing ally” and sponsor the careers of those around you, such as creating safe spaces to have these conversations because not everyone is bold enough to speak up or to ask for support since raising issues in a public forum can be intimidating. Making yourself accessible and providing anonymous forms for suggestions or feedback can serve as opportunities to educate yourself and to increase awareness of diverging opinions.

An audience member stated that recognizing an action that is alienating to a member of your group—even just acknowledging their experience or saying something to the room—can be very powerful to create a sense of safety and belonging. And another said that those in leadership positions being forthright about the limits of their knowledge, gives people the freedom to not know everything.

So to Minu’s question, what should we do to improve Bazel’s culture?

Helen: Create a governance group on Slack to ensure posts are complying with the community code of conduct guidelines. Review how this is managed for other OSS communities.

Sophia: Institutionalize mentorship; have someone else review what you’ve done and give you the confidence to push a change. Nurture people. We need to connect new and established members of the community.

Lyra: Recruit people in parallel careers paths with higher representation. Give them sponsorship to transition to tech.

Radhika: Be more inclusive. All the jargon can get overwhelming, so let’s consider how we can make things simpler, including with non-technical metaphors.

Eva: Consider what each of us can do to make the experience for people onboarding better.

There are more ways to be a Bazel contributor than raising PRs. Being courageous, vulnerable and open contributes to the culture that creates the code. Maintainers: practice empathy and remember the human on the other side of the screen. Be a coach and a mentor, knowing that you are opening the door for more people to build the product you love, with you. Developers: be brave and see the opportunities to accept sponsorship into the space. Bazel is for everyone.

By Lyra Levin, Minu Puranik, Keerthana Kumar, Radhika Advani, and Sophia Vargas – Bazel Panel

Writing fuzz tests with ease using Bazel

We are announcing Bazel support for developing and testing fuzz tests, with OSS-Fuzz integration, through the new rules_fuzzing Bazel library.

Fuzzing is an effective, well-known testing technique for finding security and stability bugs in software. But writing and testing fuzz tests can be tedious. Developers typically need to:

• Implement a fuzz driver function, which exercises the API under test;
• Build the code with the proper instrumentation (such as Address Sanitizer);
• Link it with one of the available fuzzing engine libraries (libFuzzer, AFL++, Honggfuzz, etc.) that provide the core test generation logic;
• Run the fuzz test binary with the right set of flags (e.g., to specify corpora or dictionaries);
• Package the fuzz test and its resources for consumption by fuzzing infrastructures, such as OSS-Fuzz.

Unfortunately, build systems don't traditionally offer any support beyond the core primitives of producing executables, so projects adopting fuzzing often end up reimplementing fuzz test recipes.

Bazel is a versatile and extensible build system, focused on scalable, reliable, and reproducible builds. Originally designed to scale to Google's entire monolithic repository, it now underpins large enterprises and key open source Internet infrastructure projects.

We are pleased to announce that projects using Bazel can get advanced fuzzing support through the new rules_fuzzing extension library. The new fuzzing rules take care of all the boilerplate needed to build and run fuzz tests. Developers simply write the fuzz driver code and define a build target for it (example driver and target for RE2). Fuzz tests can be built and run using a number of fuzzing engines provided out-of-the-box, such as libFuzzer and Honggfuzz, as well as sanitizers. The rule library also provides the ability to define additional fuzzing engines.

You can integrate the fuzzing library with around 10 LOC in your Bazel WORKSPACE file. Defining a fuzz test in Bazel is as easy as writing the following in your BUILD file:

load("@rules_fuzzing//fuzzing:cc_deps.bzl, "cc_fuzz_test")
cc_fuzz_test(
   name = "my_fuzz_test",
   srcs = ["my_fuzz_test.cc"],
   deps = [":my_library"],
)

You can easily test the fuzzer locally by invoking its launcher:

$ bazel run --config=asan-libfuzzer //:my_fuzz_test_run

To improve the effectiveness of test case generation, fuzz tests also support seed corpora and dictionaries, through additional rule attributes. They will automatically be validated and included in fuzz test runs. Fuzz tests also serve as regression tests on the seed corpus. For example, you can add previously found and fixed crashes to the corpus and have them tested in your CI workflows:

$ bazel test --config=asan-replay //:my_fuzz_test

The fuzzing rules provide built-in support for OSS-Fuzz, our continuous fuzzing service for open source projects. The OSS-Fuzz support drastically simplifies writing the build scripts in project integration by automatically packaging the fuzz test and its dependencies using the expected OSS-Fuzz structure.

The Envoy Proxy project is one of the early adopters of the fuzzing rules library. As a large, mature C++ codebase, Envoy has maintained its own custom implementation of fuzzing support for its over 50 fuzz targets written so far. By switching to the new Bazel fuzzing rules, Envoy's fuzz targets automatically gained new features, such as local running and testing tools and support for multiple fuzzing engines. At the same time, Envoy simplified its OSS-Fuzz integration scripts. Moreover, it will automatically gain future functionality (e.g., more effective fuzzing engines, better coverage tracking, improved corpus management) as the Bazel fuzzing rules library evolves.

The Bazel rules for fuzzing draw from Google's experience providing effective fuzzing tools to our internal developers. We hope the new Bazel support for fuzzing will lower the barrier to fuzzing adoption in open source communities, further increasing the security and reliability of many projects. To learn more about integrating the fuzzing rules into your project, take a look at the Getting Started section in the documentation.

By Stefan Bucur, Software Analysis, Asra Ali, Envoy, and Abhishek Arya, OSS-Fuzz – Google

Welcome Android Open Source Project (AOSP) to the Bazel ecosystem

After significant investment in understanding how best to build the Android Platform correctly and quickly, we are pleased to announce that the Android Platform is migrating from its current build systems (Soong and Make) to Bazel. While components of Bazel have been already checked into the Android Open Source Project (AOSP) source tree, this will be a phased migration over the next few Android releases which includes many concrete and digestible milestones to make the transformation as seamless and easy as possible. There will be no immediate impact to the Android Platform build workflow or the existing supported Android Platform Build tools in 2020 or 2021. Some of the changesto support Android Platform builds are already in Bazel, such as Bazel’s ability to parse and execute Ninja files to support a gradual migration.

Migrating to Bazel will enable AOSP to:

• Provide more flexibility for configuring the AOSP build (better support for conditionals)
• Allow for greater introspection into the AOSP build progress and dependencies
• Enable correct and reproducible (hermetic) AOSP builds
• Introduce a configuration mechanism that will reduce complexity of AOSP builds
• Allow for greater integration of build and test activities
• Combine all of these to drive significant improvements in build time and experience

The benefits of this migration to the Bazel community are:

• Significant ongoing investment in Bazel to support Android Platform builds
• Expansion of the Bazel ecosystem and community to include, initially, tens of thousands of Android Platform developers and Android handset OEMs and chipset vendors.
• Google’s Bazel rules for building Android apps will be open sourced, used in AOSP, and maintained by Google in partnership with the Android / Bazel community
• Better Bazel support for building Android Apps
• Better rules support for other languages used to build Android Platform (Rust, Java, Python, Go, etc)
• Strong support for Bazel Long Term Support (LTS) releases, which benefits the expanded Bazel community
• Improved documentation (tutorials and reference)

The recent check-in of Bazel to AOSP begins an initial pilot phase, enabling Bazel to be used in place of Ninja as the execution engine to build AOSP. Bazel can also explore the AOSP build graph. We're pleased to be developing this functionality directly in the Bazel and AOSP codebases. As with most initial development efforts, this work is experimental in nature. Remember to use the currently supported Android Platform Build System for all production work.

We believe that these updates to the Android Platform Build System enable greater developer velocity, productivity, and happiness across the entire Android Platform ecosystem.

By Joe Hicks on behalf of the Bazel and AOSP infrastructure teams

Get ready for BazelCon 2020

With only 24 hours to go, BazelCon 2020 is shaping up to be a much anticipated gathering for the Bazel community and broader Build ecosystem. With over 1000 attendees, presentations by Googlers, as well as talks from industry Build leaders from Twitter, Dropbox, Uber, Pinterest, GrabTaxi, and more, we hope BazelCon 2020 will provide an opportunity for knowledge sharing, networking, and community building.

I am very excited by the keynote announcements, the migration stories at Twitter, Pinterest, and CarGurus, as well as technical deep dives on Bazel persistent workers, incompatible target skipping, migrating from Gradle to Bazel, and more. The “sold out” Birds of a Feather sessions and the Live Q&A with the Bazel team will bring the community together to discuss design docs, look at landings, and provide feedback on the direction of Bazel and the entire ecosystem.

We are also pleased to announce that, starting with the next major release (4.0), Bazel will support Long Term Support (LTS) releases as well as regular Rolling releases.

Some benefits of this new release cadence are:

• Bazel will release stable, supported LTS releases on a predictable schedule with a long window without breaking changes
• Bazel contributors / rules owners can prepare to support future LTS releases via rolling releases.
• Bazel users can choose the release cadence that works best for them, since we will offer both LTS releases and rolling releases.

Long Term Support (LTS) releases:

• We will create an LTS release every ~9 months => new LTS release branch, increment major version number.
• Each LTS release will include all new features, bug fixes and (breaking) changes since the last major version.
• Bazel will actively support each LTS branch for 9 months with critical bug fixes, but no new features.
• Thereafter, Bazel will provide maintenance for two additional years with only security and OS compatibility fixes.
• Bazel Federation reboot: Bazel will provide strong guidance about the ruleset versions that should be used with each Bazel release so that each user will not have to manage interoperability themselves.

Make sure that you register at http://goo.gle/bazelcon to be a part of the excitement of the premier build conference!

See you all at BazelCon 2020!

By Joe Hicks and the entire Bazel Team at Google

BazelCon 2019

Cross-posted from the original BazelCon 2019 recap .

Last month the Google Bazel team hosted its largest ever Bazel user conference: BazelCon 2019, an annual gathering of the community surrounding the Bazel build system. This is the main Bazel event of the year which serves as an opportunity for Bazel contributors, maintainers, and users to meet and learn from each other, present Bazel migration stories, educate new users, and collaborate together on the future of Bazel.

BazelCon 2019 by the Numbers

• 400+ attendees (2x increase over BazelCon 2018)
• 125 organizations represented including Microsoft, Spotify, Uber, Apple, Cruise, EA, Lyft, Tesla, SpaceX, SAP, Bloomberg, Wix, Etsy, BMW and others
• 26 full-length talks and 15 lightning talks by members of the external community and Googlers
• 16 hours of Q&A during Office Hours with Bazel team members
• 45 Bazel Bootcamp attendees
• 5 Birds of a Feather sessions on iOS, Python, Java, C++ and Front-end Bazel rules
• 182 users in the #bazelcon2019 Slack channel

BazelCon 2019 Full Length Talks

The full playlist also includes lighting talks.

• Keynote: The Role of Catastrophic Failure in Software Design – Jeff Atwood (Stack Overflow/Discourse)
• Bazel State of the Union – John Field and Dmirty Lomov (Google)
• Building Self Driving Cars with Bazel – Axel Uhlig and Patrick Ziegler (BMW Group)
• Moving to a Bazel-based CI system: 6 Learnings – Or Shachar (Wix)
• Bazel Federation – Florian Weikert (Google)
• Lessons from our First 100,000 Bazel Builds – Kevin Gessner (Etsy)
• Migrating Lyft-iOS to Bazel – Keith Smiley and Dave Lee (Lyft)
• Test Selection – Benjamin Peterson (Dropbox)
• Porting iOS Apps to Bazel – Oscar Bonilla (LinkedIn)
• Boosting Dev Box Performance with Remote Execution for Non-Hermetic Build Engines – Erik Mavrinac (Microsoft)
• Building on Key - Keeping your Actions and Remote Executions in Tune – George Gensure (UberATG)
• Bazel remote execution API vs Goma – Mostyn Bramley-Moore (Vewd Software)
• Integrating with ease: leveraging BuildStream interaction with Bazel build for consistent results – Daniel Silverstone (Codethink)
• Building Self-Driving Cars with Bazel – Michael Broll and Nico Valigi (Cruise)
• Make local development (with Bazel) great again! – Ittai Zeidman (Wix)
• Gradle to Bazel – Chip Dickson and Charles Walker (SUM Global Technology)
• Bazel Bootcamp – Kyle Cordes (Oasis Digital)
• Bazel migration patterns: how to prove business value with a small investment – Alex Eagle and Greg Magolan (Google)
• Dynamic scheduling: Fastest clean and incremental builds – Julio Merino (Google)
• Building a great CI with Bazel – Philipp Wollermann (Google)

By Misha Narinsky, Bazel Team

Bazel Reaches 1.0 Milestone!

We're excited to announce the first General Availability release of Bazel, an open source build system designed to support a wide variety of programming languages and platforms.

Bazel was born of Google's own needs for highly scalable builds. When we open sourced Bazel back in 2015, we hoped that Bazel could fulfill similar needs in the software development industry. A growing list of Bazel users attests to the widespread demand for scalable, reproducible, and multi-lingual builds. Bazel helps Google be more open too: several large Google open source projects, such as Angular and TensorFlow, use Bazel. Users have reported 3x test time reductions and 10x faster build speeds after switching to Bazel.

With the 1.0 release we’re continuing to implement Bazel's vision:

• Bazel builds are fast and correct. Every build and test run is incremental, on your developers’ machines and on your CI test system.
• Bazel supports multi-language, multi-platform builds and tests. You can run a single command to build and test your entire source tree, no matter which combination of languages and platforms you target.
• Bazel provides a uniform extension language, Starlark, to define builds for any language or platform.
• Bazel works across all major development platforms (Linux, macOS, and Windows).
• Bazel allows your builds to scale—it connects to distributed remote execution and caching services.

The key features of the 1.0 GA release are:

• Semantic Versioning

Starting with Bazel 1.0, we will use semantic versioning for all Bazel releases. For example, all 1.x releases will be backwards-compatible with Bazel 1.0. We will have a window of at least three months between major (breaking) releases. We'll continue to publish minor releases of Bazel every month, cutting from GitHub HEAD.

• Long-Term Support

Long-Term Support (LTS) releases give users confidence that the Bazel team has the capacity and the process to quickly and safely deliver fixes for critical bugs, including vulnerabilities.

• Well-rounded features for Angular, Android, Java, and C++

The new features include end-to-end support for remote execution and caching, and support for standard package managers and third-party dependencies.

New to Bazel? Try the tutorial for your favorite language to get started.

With the 1.0 release we still have many exciting developments ahead of us. Follow our blog or Twitter account for regular updates. Feel free to contact us with questions or feedback on the mailing list, submit feature requests (and report bugs) in our GitHub issue tracker, and join our Slack channel. Finally, join us at the largest-ever BazelCon conference in December 2019 for an opportunity to meet other Bazel users and the Bazel team at Google, see demos and tech talks, and learn more about fast, correct, and large-scale builds.

Last but not least, we wouldn't have gotten here without the continued trust, support, encouragement, and feedback from the community of Bazel users and contributors. Heartfelt thanks to all of you from the Bazel team!

By Dmitry Lomov, Bazel Team

Building a Build System: Bazel reaches Beta

We're excited to announce the Beta release of Bazel, an open source build system designed to support a wide variety of different programming languages and platforms.

There are lots of other build systems out there -- Maven, Gradle, Ant, Make, and CMake just to name a few. So what’s special about Bazel? Bazel is what we use to build the large majority of software within Google. As such, it has been designed to handle build problems specific to Google’s development environment, including a massive, shared code repository in which all software is built from source, a heavy emphasis on automated testing and release processes, and language and platform diversity. Bazel isn’t right for every use case, but we believe that we’re not the only ones facing these kinds of problems and we want to contribute what we’ve learned so far to the larger developer community.

Our Beta release provides:

• Binary releases for Linux and OS X.
• Support for building and testing C++, Java, Python, Rust, and more.
• Support for building Docker images, Android apps, and iOS apps.
• Support for using libraries from Maven, GitHub, and more.
• A robust API for adding your own build rules.

Check out the tutorial app to see a working example using several languages.

We still have a long way to go.  Looking ahead towards our 1.0.0 release, we plan to provide Windows support, distributed caching, and Go support among other features. See our roadmap for more details and follow our blog or Twitter account for regular updates.  Feel free to contact us with questions or feedback on the mailing list or IRC (#bazel on freenode).

By Jeff Cox, Bazel team