Bazel Concepts: Difference between revisions
| Line 10: | Line 10: | ||
{{External|https://bazel.build/concepts/build-ref#packages}} | {{External|https://bazel.build/concepts/build-ref#packages}} | ||
A package is the primary unit of code organization in a repository. A package is a collection of related files, and a specification, embodied by the [[Bazel_BUILD_Files#Overview|BUILD file]], of how these files can be used to produce artifacts. The directory that contains the BUILD file is called the package directory. The package contains all the files from the package directory, and recursively, from all its subdirectories, except those which themselves contain a BUILD file. | A package is the primary unit of code organization in a repository. A package is a collection of related files, and a specification, embodied by the [[Bazel_BUILD_Files#Overview|BUILD file]], of how these files can be used to produce artifacts. The directory that contains the BUILD file is called the <span id='Package_Directory'></span>'''package directory'''. The package contains all the files from the package directory, and recursively, from all its subdirectories, except those which themselves contain a BUILD file. | ||
=Target= | =Target= | ||
Revision as of 21:10, 20 September 2024
Internal
Repository
repositories.bzl
Package
A package is the primary unit of code organization in a repository. A package is a collection of related files, and a specification, embodied by the BUILD file, of how these files can be used to produce artifacts. The directory that contains the BUILD file is called the package directory. The package contains all the files from the package directory, and recursively, from all its subdirectories, except those which themselves contain a BUILD file.
Target
Label
BUILD files
Dependencies
Build Dependency Graph
Also see:
Visibility
Platforms
Rules
Hermeticity
Directories
Workspace
A project's workspace is the directory where bazel looks for build inputs and BUILD files, and where it stores build outputs. The actual location is obtained with bazel info.
Bin
The actual location is obtained with bazel info.
Genfiles
The actual location is obtained with bazel info.
Testlogs
The actual location is obtained with bazel info.
Execution Root
The actual location is obtained with bazel info.
Install Base
The actual location is obtained with bazel info.
Output Base
The actual location is obtained with bazel info.
Output Path
The actual location is obtained with bazel info.
Package Path
%workspace%. See Workspace.
Repository Cache
The actual location is obtained with bazel info.
Files
Server Log
The actual location is obtained with bazel info.
Command Log
The actual location is obtained with bazel info.
.bazelrc
Project View File
Seems to be this one:
directories:
# Add the directories you want added as source here
# By default, we've added your entire workspace ('.')
.
# Automatically includes all relevant targets under the 'directories' above
derive_targets_from_directories: true
targets:
# If source code isn't resolving, add additional targets that compile it here
additional_languages:
# Uncomment any additional languages you want supported
# android
# dart
# go
# javascript
# kotlin
# python
# scala
# typescript
# Uncomment to run this target before every sync
# gazelle_target: //:gazelle
BUILD File
Starlark
Bazelisk
A bazel runner. as "Bazel binary location" in the Bazel IntelliJ Plugin.
Bazel and IntelliJ
Sync Process
The sync process queries Bazel for information and builds IntelliJ project structure to fid Bazel's model. It runs automatically during a project import, and manually by clicking on the sync icon in the menu bar, or partially syncing packages and individual files in contextual menus.
If the file is not reachable from Bazel targets, it will show up as unsynced in the IDE.
TODO: https://blog.bazel.build/2019/09/29/intellij-bazel-sync.html
rules_go
Reconcile with Bazel_BUILD_Files#Build_Rules.
nogo
nogo is a tool that analyzes source code of Go programs. It runs alongside the Go compiler in the Bazel Go rules and rejects programs that contain disallowing coding patterns. In addition, nogo may report compiler-like errors. It may be used to run the same analyses as vet. The nogo rule will generate a program that executes all the supplied analyzers at build-time. The generated nogo program will run alongside the compiler when building any Go target (e.g. go_library) within your workspace, even if the target is imported from an external repository. However, nogo will not run when targets from the current repository are imported into other workspaces and built there.
Analyzers
nogo Setup
To activate nogo, declare a nogo target in the BUILD file.
load("@io_bazel_rules_go//go:def.bzl", "nogo")
nogo(
name = "my_nogo",
deps = [
# analyzer from the local repository
":importunsafe",
# analyzer from a remote repository
"@org_golang_x_tools//go/analysis/passes/printf:go_default_library",
],
visibility = ["//visibility:public"], # must have public visibility
)
go_library(
name = "importunsafe",
srcs = ["importunsafe.go"],
importpath = "importunsafe",
deps = ["@org_golang_x_tools//go/analysis:go_default_library"],
visibility = ["//visibility:public"],
)
nogo Configuration
nogo is configured with a JSON file that specifies analyzers:
{
"structtag": {
"exclude_files": {
"vendor/": "vendor tools don't pass vet",
"external/": "external tools don't pass vet"
}
},
"exhaustive": {
"exclude_files": {
"vendor/": "vendor tools don't pass vet",
"external/": "external tools don't pass vet"
}
},
...
}
To exclude completely all files:
"exhaustive": {
"exclude_files": {
".*": "disable completely"
}
},
gazelle
Updates Bazel configuration files.
Example:
bazel run //:gazelle -- update-repos golang.org/x/sys@v0.13.0
adds the following line to the WORKSPACE file:
go_repository(
name = "org_golang_x_sys",
importpath = "golang.org/x/sys",
sum = "h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=",
version = "v0.13.0",
)
vet
Also see nogo.