Introduce initial Bazel build #1705
No reviewers
Labels
No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk!1705
Loading…
Reference in a new issue
No description provided.
Delete branch "initial-bazel-build"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Introduces the beginnings of a Bazel build for the Raspberry Pi Pico. The vast majority of preexisting build system configuration options are missing, but the build produces working binaries when used from an external project.
@ -0,0 +1,71 @@module(name = "pico-sdk", version = "1.6.0-rc1")I have an open commit that I need to include, so I'll be updating this shortly. If needed, I can get a full release of
rules_cccut before merging this PR.@kilograham I've put together an initial PR for adding a Bazel build, I have a few minor bits of cleanup before this is fully ready to merge, but I wanted to raise it to you now so you can start sharing any feedback/questions/concerns you may have now. @tpudlik has offered to review this from the Bazel side of things.
@ -0,0 +1,137 @@# Bazel build@ -0,0 +57,4 @@build --@rules_cc//cc/toolchains:experimental_enable_rule_based_toolchains```### Ready to build!Should the README mention
pico_config_extra_headersandpico_config_platform_headers?@ -0,0 +3,4 @@# This constraint represents the dimension that guides the Pico SDK build. This# constraint will only ever enumerate specific MCUs (and the host), and does NOT# cover the differences from board-to-board.constraint_setting(The
constraint_settings should really have comments explaining what they mean!Eventually, will each header in
src/boards/include/boardshave a correspondingsdk_targetconstraint_value?Why introduce a variable for
maybe_condinstead of just inlining it in theifstatement?@ -0,0 +4,4 @@name = "rp2040",constraint_values = ["@pico-sdk//bazel/constraint:rp2040","@platforms//cpu:armv6-m", # This is just FYI.If we don't actually refer to it, I'd remove it.
@ -0,0 +1,151 @@load("@rules_cc//cc/toolchains:args.bzl", "cc_args")Do we have a bug to reference here?
@ -0,0 +1,46 @@load("@bazel_tools//tools/build_defs/cc:action_names.bzl", "OBJ_COPY_ACTION_NAME")https://github.com/bazelbuild/bazel/pull/16158 added it in the Bazel version. Do you mean it's not in the
rules_ccversion? Should we create a FR?@ -0,0 +97,4 @@)alias(name = "default",I would maybe call this
boards. That's a special target name in that@pico-sdk//src/boards:boardscan be abbreviated to just@pico-sdk//src/boardsin lists of deps, etc. So it's weird to reserve this "most public" name for a target that's private and intended to be burned down!Unless we want to hide the alias behind a
label_flag, to allow SDK users to provide their own board definitions.@ -0,0 +1,103 @@load("@bazel_skylib//rules:run_binary.bzl", "run_binary")Could the comment explain why we need to be careful? What should the maintainers be carefully watching out for?
@ -0,0 +1,99 @@load("@bazel_skylib//rules:copy_file.bzl", "copy_file")Shouldn't
asmincludego in here instead of line 28?Consider using
copy_filefrom Skylib, which has a simpler, cross-platform (Windows-friendly) interface: https://github.com/bazelbuild/bazel-skylib/blob/main/docs/copy_file_doc.mdConsider using
run_binaryfrom Skylib, which doesn't rely on the shell (https://github.com/bazelbuild/bazel-skylib/blob/main/docs/run_binary_doc.md). From the docs:@ -0,0 +16,4 @@"include/pico/async_context_threadsafe_background.h",],includes = ["include"],# Missing deps for:Will all of these come from FreeRTOS? Another reason to upstream our FreeRTOS build file (https://pwbug.dev/326625641)!
@ -0,0 +1,23 @@package(default_visibility = ["//visibility:public"])Could you expand the TODO to mention why that's nontrivial?
Ready for another pass! :)
@ -0,0 +57,4 @@build --@rules_cc//cc/toolchains:experimental_enable_rule_based_toolchains```### Ready to build!Added instructions for these. They'll get totally reworked shortly, but it's good to document what's there!
@ -0,0 +3,4 @@# This constraint represents the dimension that guides the Pico SDK build. This# constraint will only ever enumerate specific MCUs (and the host), and does NOT# cover the differences from board-to-board.constraint_setting(No, I don't think we'll have a constraint for each board. I've added a comment to clarify. After this first PR is merged, I'll be focusing on doing a comprehensive pass over the SDK configuration and then provide better foundations for configuration options. I have some ideas here, but I'd rather build those out as a separate PR so we can review/discuss them in isolation.
Not relevant anymore.
@ -0,0 +4,4 @@name = "rp2040",constraint_values = ["@pico-sdk//bazel/constraint:rp2040","@platforms//cpu:armv6-m", # This is just FYI.This is a well-known constraint though. Since there's a correct value, I feel we should just configure it so people aren't left confused as to why it's unset.
@ -0,0 +1,151 @@load("@rules_cc//cc/toolchains:args.bzl", "cc_args")Filed https://github.com/bazelbuild/rules_cc/issues/224
@ -0,0 +1,46 @@load("@bazel_tools//tools/build_defs/cc:action_names.bzl", "OBJ_COPY_ACTION_NAME")Yeah, it's not yet in
rules_cc:github.com/bazelbuild/rules_cc@1acf5213b6/cc/action_names.bzlSwitched to use
@bazel_tools//tools/build_defs/cc:action_names.bzlfor now.@ -0,0 +97,4 @@)alias(name = "default",The alias is behind a label flag:
//bazel/config:pico_config_header. I renamedboardstounsupported_boardsfor now. I'll be taking a pass over comprehensive support for this in a follow-up.@ -0,0 +1,103 @@load("@bazel_skylib//rules:run_binary.bzl", "run_binary")Updated comment.
@ -0,0 +1,99 @@load("@bazel_skylib//rules:copy_file.bzl", "copy_file")Done
Done, much cleaner now!
Yep, fixed.
@ -0,0 +16,4 @@"include/pico/async_context_threadsafe_background.h",],includes = ["include"],# Missing deps for:Yeah, these are all provided by FreeRTOS. Interestingly I'm not seeing CMake configuration options for turning this on/off despite it seeming to be an optional feature. I'll mark this on my TODO list.
@ -0,0 +1,23 @@package(default_visibility = ["//visibility:public"])Updated here and elsewhere. TL;DR: we need to set up configuration patterns since it's mutually exclusive.
I trust that this has stabilized enough for a baseline build... since it is entirely orthogonal to the CMake build, it can evolve independently.