{"id":1807,"date":"2026-05-24T15:21:23","date_gmt":"2026-05-24T22:21:23","guid":{"rendered":"https:\/\/nanzhou.cc\/?p=1807"},"modified":"2026-05-24T15:41:54","modified_gmt":"2026-05-24T22:41:54","slug":"bazel-select","status":"publish","type":"post","link":"https:\/\/nanzhou.cc\/index.php\/2026\/05\/24\/bazel-select\/","title":{"rendered":"Bazel: select"},"content":{"rendered":"\n

Think of select()<\/code> as a conditional expression<\/strong> that lives inside your build rules. It functions exactly like a switch<\/code> or if\/else<\/code> statement in a programming language, but it operates during the “analysis phase” of a Bazel build.<\/p>\n\n\n\n

See the other post<\/a> for constraint_setting and constraint_values<\/p>\n\n\n\n

1. The Core Purpose<\/h3>\n\n\n\n

When you build code, you often have minor differences based on the environment. Maybe you need a specific header file on Windows, or a different compiler flag for ARM processors. Instead of creating different build files for every platform, you use select()<\/code> to keep your build files clean and unified.<\/p>\n\n\n\n

2. How it works<\/h3>\n\n\n\n

You use select()<\/code> inside an attribute (like srcs<\/code>, deps<\/code>, copts<\/code>, or data<\/code>). It takes a dictionary where:<\/p>\n\n\n\n

    \n
  • The keys<\/strong> are config_setting<\/code> targets (which contain your constraints).<\/li>\n\n\n\n
  • The values<\/strong> are the actual data you want to use if that condition is met.<\/li>\n<\/ul>\n\n\n\n

    3. A Practical Example<\/h3>\n\n\n\n

    Imagine you are building a library that handles file paths. You need a different C++ source file depending on whether you are compiling for Windows or Linux.<\/p>\n\n\n\n

    cc_library(\n    name = \"file_utils\",\n    srcs = select({\n        \"@platforms\/\/os:windows\": [\"path_win.cc\"],\n        \"@platforms\/\/os:linux\": [\"path_linux.cc\"],\n        \"\/\/conditions:default\": [\"path_generic.cc\"], # The \"else\" case\n    }),\n)\n<\/code><\/pre>\n\n\n\n
    Sometimes a single select()<\/code> key isn’t enough. What if you want to do something only on “Linux + x86”<\/strong>? You can use config_setting<\/code> to group them:<\/p>\n\n\n\n
    # 1. Define a specific condition\nconfig_setting(\n    name = \"is_linux_x86\",\n    constraint_values = [\n        \"@platforms\/\/os:linux\",\n        \"@platforms\/\/cpu:x86_64\",\n    ],\n)\n\n# 2. Use that condition in a select\ncc_library(\n    name = \"optimized_lib\",\n    srcs = select({\n        \":is_linux_x86\": [\"optimized_x86.cc\"],\n        \"\/\/conditions:default\": [\"generic.cc\"],\n    }),\n)<\/code><\/pre>\n\n\n\n
    4. Anatomy of the select()<\/code><\/h3>\n\n\n\n
      \n
    • @platforms\/\/os:windows<\/code><\/strong>: This is your condition. If the current --platforms<\/code> flag results in an environment that has this constraint_value<\/code>, this branch is chosen.<\/li>\n\n\n\n
    • \"\/\/conditions:default\"<\/code><\/strong>: This is the required<\/strong> fallback. If none of your specific conditions match, Bazel uses this value. Your build will fail if you don’t provide this and no other condition matches.<\/li>\n\n\n\n
    • Merging<\/strong>: If you use select()<\/code> on an attribute that accepts lists (like srcs<\/code>), you can even combine them with non-selected items:Pythonsrcs = [\"common.cc\"] + select({ ... }), <\/code>Bazel will automatically concatenate the lists.<\/em><\/li>\n<\/ul>\n\n\n\n
      Why use select()<\/code> instead of just writing two different targets?<\/h3>\n\n\n\n
        \n
      1. DRY (Don’t Repeat Yourself)<\/strong>: You maintain one cc_library<\/code> target instead of having separate cc_library_win<\/code> and cc_library_linux<\/code> targets.<\/li>\n\n\n\n
      2. Type Safety<\/strong>: Bazel validates that the constraints used in your select<\/code> are valid constraint_value<\/code> types.<\/li>\n\n\n\n
      3. Efficiency<\/strong>: Bazel only computes the graph for the specific path you have chosen. It doesn’t waste time analyzing the branches that aren’t relevant to your current build.<\/li>\n<\/ol>\n\n\n\n
        In short, select()<\/code> is the tool you reach for when you want your build logic to be flexible<\/strong> enough to handle different platforms without becoming a tangled mess of duplicated rules.<\/p>\n\n\n\n
        platforms() and select()<\/h2>\n\n\n\n
        The Big Picture<\/h3>\n\n\n\n
          \n
        • Platforms<\/strong> describe the “Where”<\/strong> (the environment).<\/li>\n\n\n\n
        • select()<\/code><\/strong> describes the “What”<\/strong> (the specific code or flags needed for that environment).<\/li>\n<\/ul>\n\n\n\n
          1. Platforms (The Environment Orchestrator)<\/h3>\n\n\n\n
          A Platform<\/strong> is a collection of constraint_values<\/code> that defines a complete target hardware\/OS environment.<\/p>\n\n\n\n
            \n
          • Role:<\/strong> Acts as the master configuration for your entire build.<\/li>\n\n\n\n
          • Purpose:<\/strong>\n
              \n
            • Toolchain Resolution:<\/strong> Tells Bazel exactly which compiler, linker, and standard library to use.<\/li>\n\n\n\n
            • Compatibility:<\/strong> Defines what the environment is<\/em> (e.g., “This is a 64-bit ARM Linux machine”).<\/li>\n\n\n\n
            • Global Context:<\/strong> You set it once at the top level via the command line (e.g., --platforms=\/\/platforms:my_custom_platform<\/code>), and the entire build graph adopts that context.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
              2. select()<\/code> (The Conditional Switch)<\/h3>\n\n\n\n
              select()<\/code> is a function used inside individual rules to perform conditional logic<\/strong>.<\/p>\n\n\n\n
                \n
              • Role:<\/strong> Acts as an if\/else<\/code> or switch<\/code> statement for specific build attributes.<\/li>\n\n\n\n
              • Purpose:<\/strong>\n
                  \n
                • Code Variation:<\/strong> Swap source files (srcs<\/code>), dependencies (deps<\/code>), or compiler flags (copts<\/code>) based on specific features.<\/li>\n\n\n\n
                • Granularity:<\/strong> Allows a single target to be “smarter” about its requirements without needing separate rules for every platform.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                • How it decides:<\/strong> It looks at the constraints provided by the active platform<\/code>. If the active platform contains the constraint specified in your select()<\/code> key, that branch is chosen.<\/li>\n<\/ul>\n\n\n\n
                  Comparison Summary<\/h3>\n\n\n\n
                  Feature<\/strong><\/td>Platforms<\/strong><\/td>select()<\/strong><\/td><\/tr><\/thead>
                  Concept<\/strong><\/td>The “Environment”<\/td>The “Conditional Logic”<\/td><\/tr>
                  Scope<\/strong><\/td>Global (entire build graph)<\/td>Local (specific target attributes)<\/td><\/tr>
                  Function<\/strong><\/td>Identifies hardware\/OS capabilities<\/td>Swaps code\/flags based on those capabilities<\/td><\/tr>
                  Command Line<\/strong><\/td>Set by --platforms<\/code><\/td>Automatically reacts to --platforms<\/code><\/td><\/tr>
                  Best Analogy<\/strong><\/td>The OS running on a server<\/td>An if<\/code> statement in your code<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  The Complete Cross-Platform Workflow<\/h3>\n\n\n\n
                    \n
                  1. Define your Constraints:<\/strong> Create the constraint_setting<\/code> and constraint_value<\/code> targets (or just use the standard ones from @platforms<\/code>).\n
                      \n
                    • Example:<\/em> “I need to distinguish between Windows and Linux.”<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                    • Define your Platform:<\/strong> Group those constraints into a platform<\/code> target.\n
                        \n
                      • Example:<\/em> “Create a my_windows_machine<\/code> platform that includes @platforms\/\/os:windows<\/code>.”<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                      • Update your Targets (The crucial link!):<\/strong> Modify your existing cc_library<\/code>, cc_binary<\/code>, etc., to use select()<\/code> on their attributes. This tells the rule how<\/em> to change its behavior based on the constraints.\n
                          \n
                        • Before:<\/em> srcs = [\"default_file.cc\"]<\/code><\/li>\n\n\n\n
                        • After:<\/em> srcs = select({\"@platforms\/\/os:windows\": [\"win_file.cc\"], \"\/\/conditions:default\": [\"default_file.cc\"]})<\/code><\/li>\n<\/ul>\n<\/li>\n\n\n\n
                        • Build with the Platform:<\/strong> Run your build and tell Bazel which platform to act as.\n
                            \n
                          • Example:<\/em> bazel build \/\/my_app --platforms=\/\/:my_windows_machine<\/code><\/li>\n<\/ul>\n<\/li>\n\n\n\n
                          • Bazel Connects the Dots:<\/strong> Bazel sees the --platforms<\/code> flag, checks the platform’s constraints, looks at your cc_library<\/code>‘s select()<\/code> statement, and automatically picks win_file.cc<\/code>.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
                            Think of select() as a conditional expression that lives inside your build rules. It functions exactly like a switch or if\/else statement in a programming language, but it operates during the “analysis phase” of a Bazel build. See the other post for constraint_setting and constraint_values 1. The Core Purpose When you build code, you often…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"0","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[77],"tags":[],"class_list":["post-1807","post","type-post","status-publish","format-standard","hentry","category-Toolchain"],"_links":{"self":[{"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/posts\/1807","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/comments?post=1807"}],"version-history":[{"count":3,"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/posts\/1807\/revisions"}],"predecessor-version":[{"id":1810,"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/posts\/1807\/revisions\/1810"}],"wp:attachment":[{"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/media?parent=1807"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/categories?post=1807"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nanzhou.cc\/index.php\/wp-json\/wp\/v2\/tags?post=1807"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}