platform_build_soong/android/queryview.go

113 lines
4.1 KiB
Go
Raw Normal View History

Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
// Copyright 2020 Google Inc. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package android
import (
"fmt"
"os"
"strings"
"github.com/google/blueprint"
)
// The Bazel QueryView singleton is responsible for generating the Ninja actions
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
// for calling the soong_build primary builder in the main build.ninja file.
func init() {
RegisterSingletonType("bazel_queryview", BazelQueryViewSingleton)
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
}
// BazelQueryViewSingleton is the singleton responsible for registering the
// soong_build build statement that will convert the Soong module graph after
// applying *all* mutators, enabing the feature to query the final state of the
// Soong graph. This mode is meant for querying the build graph state, and not meant
// for generating BUILD files to be checked in.
func BazelQueryViewSingleton() Singleton {
return &bazelQueryViewSingleton{}
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
}
// BazelConverterSingleton is the singleton responsible for registering the soong_build
// build statement that will convert the Soong module graph by applying an alternate
// pipeline of mutators, with the goal of reaching semantic equivalence between the original
// Blueprint and final BUILD files. Using this mode, the goal is to be able to
// build with these BUILD files directly in the source tree.
func BazelConverterSingleton() Singleton {
return &bazelConverterSingleton{}
}
type bazelQueryViewSingleton struct{}
type bazelConverterSingleton struct{}
func generateBuildActionsForBazelConversion(ctx SingletonContext, converterMode bool) {
name := "queryview"
descriptionTemplate := "[EXPERIMENTAL, PRE-PRODUCTION] Creating the Bazel QueryView workspace with %s at $outDir"
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
// Create a build and rule statement, using the Bazel QueryView's WORKSPACE
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
// file as the output file marker.
var deps Paths
moduleListFilePath := pathForBuildToolDep(ctx, ctx.Config().moduleListFile)
deps = append(deps, moduleListFilePath)
deps = append(deps, pathForBuildToolDep(ctx, ctx.Config().ProductVariablesFileName))
bazelQueryViewDirectory := PathForOutput(ctx, name)
bazelQueryViewWorkspaceFile := bazelQueryViewDirectory.Join(ctx, "WORKSPACE")
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
primaryBuilder := primaryBuilderPath(ctx)
bazelQueryView := ctx.Rule(pctx, "bazelQueryView",
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
blueprint.RuleParams{
Command: fmt.Sprintf(
`rm -rf "${outDir}/"* && `+
`mkdir -p "${outDir}" && `+
`echo WORKSPACE: $$(cat "%s") > "${outDir}/.queryview-depfile.d" && `+
`BUILDER="%s" && `+
`echo BUILDER=$$BUILDER && `+
`cd "$$(dirname "$$BUILDER")" && `+
`echo PWD=$$PWD && `+
`ABSBUILDER="$$PWD/$$(basename "$$BUILDER")" && `+
`echo ABSBUILDER=$$ABSBUILDER && `+
`cd / && `+
`env -i "$$ABSBUILDER" --bazel_queryview_dir "${outDir}" "%s"`,
moduleListFilePath.String(), // Use the contents of Android.bp.list as the depfile.
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
primaryBuilder.String(),
strings.Join(os.Args[1:], "\" \""),
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
),
CommandDeps: []string{primaryBuilder.String()},
Description: fmt.Sprintf(
descriptionTemplate,
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
primaryBuilder.Base()),
Deps: blueprint.DepsGCC,
Depfile: "${outDir}/.queryview-depfile.d",
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
},
"outDir")
ctx.Build(pctx, BuildParams{
Rule: bazelQueryView,
Output: bazelQueryViewWorkspaceFile,
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
Inputs: deps,
Args: map[string]string{
"outDir": bazelQueryViewDirectory.String(),
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
},
})
// Add a phony target for generating the workspace
ctx.Phony(name, bazelQueryViewWorkspaceFile)
}
func (c *bazelQueryViewSingleton) GenerateBuildActions(ctx SingletonContext) {
generateBuildActionsForBazelConversion(ctx, false)
}
func (c *bazelConverterSingleton) GenerateBuildActions(ctx SingletonContext) {
generateBuildActionsForBazelConversion(ctx, true)
Create a AOSP Bazel overlay workspace with Soong The Bazel overlay is a directory at out/soong/bazel_overlay that replicates the layout of the AOSP Soong module tree, but as a Bazel workspace. Each Soong module variant is represented as a BUILD target created with the `soong_module` rule. To create this overlay, run `m bazel_overlay`. A `soong_module` target can depend on other `soong_module` targets. These dependencies replicate each module's `directDeps` in the Blueprint graph, just before `PrepareBuildActions`. This enables users to use bazel query as a way to introspect the Soong module graph. For example, - Direct reverse dependencies of //bionic/libc:generated_android_ids in //bionic/libc/...: $ bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' //bionic/libc:libc_bionic_ndk--android_recovery_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_ramdisk_arm_armv7-a-neon_static //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static_com.android.runtime //bionic/libc:libc_bionic_ndk--android_arm_armv7-a-neon_static //bionic/libc:generated_android_ids - Why does com.android.runtime depend on lzma? $ bazel query 'somepath(//bionic/apex:com.android.runtime--android_common_com.android.runtime_image, //external/lzma/...)' //bionic/apex:com.android.runtime--android_common_com.android.runtime_image //bionic/libc/malloc_debug:libc_malloc_debug--android_arm_armv7-a-neon_shared_com.android.runtime //system/core/libunwindstack:libunwindstack--android_arm_armv7-a-neon_shared_com.android.runtime //external/lzma/C:liblzma--android_arm_armv7-a-neon_shared_com.android.runtime - What does the dep graph of //bionic/libc:crtbegin_so look like? $ bazel query 'deps(//bionic/libc:crtbegin_so--android_arm_armv7-a-neon)' --output=graph > graph.in && dot -Tpng < graph.in > graph.png https://photos.app.goo.gl/DfsdoFRNsRjGwTmy8 Test: croot && m bazel_overlay && cd out/soong/bazel_overlay && bazel query //... && bazel query 'rdeps(//bionic/libc/..., //bionic/libc:generated_android_ids, 1)' Signed-off-by: Jingwen Chen <jingwen@google.com> Change-Id: I3bf40309bfb2d963bb8a688706385a57ee304c37#
2020-07-15 18:06:41 +08:00
}