Tuesday, July 16, 2019

Google Bazel Tips and Tricks



https://awesomebazel.com/

install bazel
https://docs.bazel.build/versions/master/install-ubuntu.html
https://docs.bazel.build/versions/master/tutorial/java.html

Using Maven dependencies in Bazel
https://github.com/bazelbuild/rules_jvm_external

https://docs.bazel.build/versions/master/migrate-maven.html

https://blog.bazel.build/2019/03/31/rules-jvm-external-maven.html


https://www.braintreepayments.com/blog/migrating-from-gradle-to-bazel/
Bazel’s //… syntax means build everything):
% time bazel build //...

https://brownbear.tech/blog/bazel-maven-jar
maven_jar(
    name = "com_google_guava",
    artifact = "com.google.guava:guava:27.0.1-jre"
)

After adding the maven_jar statement to your WORKSPACE file, you can start accessing the jar from your project BUILD files. Modify the deps as seen in the example below to add the Google guava library to your project.

java_binary(
    name = "project",
    deps = [
        "@com_google_guava/jar",
    ],
)
https://junctionbox.ca/2019/06/20/Maven-to-bazel-prep.html
Works best with monorepos
Bazel can be used with a number of project structures but it is most efficient when employed in a monorepo. It uses a file named WORKSPACE to indicate the project root and load dependencies like language plugins. While it is possible to stitch together traditional repos in a multi-workspace configuration it becomes cumbersome resolving and manage third-party dependencies across repos. Multirepos also bring additional overhead as it abandons the maven concept of manually versioned modules. Instead it expects repos to be in the master/HEAD position with changes being committed atomically across the project

The migration process itself for an existing project can be quite labor intensive. There’s a number of tools out there that aim to help (bazel-deps, rules_jvm_external, etc) but none of them are a complete solution. Maven is pretty lax in the specification of dependencies whereas Bazel is quite strict. Part of its speed is not having to solve version compatibility during the build. This means if you’re project isn’t using a BOM to manage versions it’s likely you’ll have multiple versions inflight, something Bazel will reject in the same dependency graph. As a result introduce a BOM and lift all the dependency versions to it before migrating to Bazel
https://codelabs.developers.google.com/codelabs/bazel-android-intro/index.html?index=..%2F..index#2
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "build_bazel_rules_android",
    urls = ["https://github.com/bazelbuild/rules_android/archive/v0.1.1.zip"],
    sha256 = "cd06d15dd8bb59926e4d65f9003bfc20f9da4b2519985c27e190cddc8b7a7806",
    strip_prefix = "rules_android-0.1.1",
)

# Configure Android SDK Path
load("@build_bazel_rules_android//android:rules.bzl", "android_sdk_repository")
android_sdk_repository(
    name = "androidsdk",
    path = "/Users/codelab/Library/Android/sdk", # Path to Android SDK, optional if $ANDROID_HOME is set
)


bazelbuild/tools_jvm_autodeps (Jadep): Generate BUILD files automatically for an existing Java project with class dependency analysis.



https://docs.bazel.build/versions/master/ide.html

Prefer http_archive to git_repository and new_git_repository.

https://github.com/gautamraj/bazel-java

https://docs.bazel.build/versions/master/external.html
s as special:
  • The WORKSPACE file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project’s directory structure,
  • One or more BUILD files, which tell Bazel how to build different parts of the project. (A directory within the workspace that contains a BUILD file is a package
BUILD file contains several different types of instructions for Bazel. The most important type is the build rule, which tells Bazel how to build the desired outputs, such as executable binaries or libraries. Each instance of a build rule in the BUILD file is called a target and points to a specific set of source files and dependencies. A target can also point to other targets.
Take a look at the java-tutorial/BUILD file:
java_binary(
    name = "ProjectRunner",
    srcs = glob(["src/main/java/com/example/*.java"]),
)
In our example, the ProjectRunner target instantiates Bazel’s built-in java_binary rule. The rule tells Bazel to build a .jar file and a wrapper shell script (both named after the target).

bazel build //:ProjectRunner
Notice the target label - the // part is the location of our BUILD file relative to the root of the workspace (in this case, the root itself), and ProjectRunner is what we named that target in the BUILD file.
Now test your freshly built binary:
bazel-bin/ProjectRunner

Depending on other Bazel projects

If you want to use targets from a second Bazel project, you can use local_repositorygit_repository or http_archive to symlink it from the local filesystem, reference a git repository or download it (respectively).
For example, suppose you are working on a project, my-project/, and you want to depend on targets from your coworker’s project, coworkers-project/. Both projects use Bazel, so you can add your coworker’s project as an external dependency and then use any targets your coworker has defined from your own BUILD files. You would add the following to my_project/WORKSPACE:
local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
)
If your coworker has a target //foo:bar, your project can refer to it as @coworkers_project//foo:bar. External project names must be valid workspace names, so _ (valid) is used to replace - (invalid) in the name coworkers_project.
https://docs.bazel.build/versions/master/be/overview.html
Native rules ship with the Bazel binary and do not require a load statement. Native rules are available globally in BUILD files. In .bzl files, you can find them in the native module.


https://github.com/bazelbuild/bazel/wiki/Bazel-Users
https://github.com/bazelbuild/bazel
Before you can build a project, you need to set up its workspace. A workspace is a directory that holds your project’s source files and Bazel’s build outputs. It also contains files that Bazel recognizes as special:
  • The WORKSPACE file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project’s directory structure,
  • One or more BUILD files, which tell Bazel how to build different parts of the project. (A directory within the workspace that contains a BUILD file is a package
  • To designate a directory as a Bazel workspace, create an empty file named WORKSPACE in that directory.
When Bazel builds the project, all inputs and dependencies must be in the same workspace. Files residing in different workspaces are independent of one another unless linked


Each instance of a build rule in the BUILD file is called a target and points to a specific set of source files and dependencies. A target can also point to other targets.

java_binary(
    name = "ProjectRunner",
    srcs = glob(["src/main/java/com/example/*.java"]),
)
bazel build //:ProjectRunner
Notice the target label - the // part is the location of our BUILD file relative to the root of the workspace (in this case, the root itself), and ProjectRunner is what we named that target in the BUILD file. (You will learn about target labels in more detail at the end of this tutorial.)

bazel-bin/ProjectRunner

Let’s visualize our sample project’s dependencies. First, generate a text representation of the dependency graph (run the command at the workspace root):
bazel query  --nohost_deps --noimplicit_deps "deps(//:ProjectRunner)" --output graph
The above command tells Bazel to look for all dependencies for the target //:ProjectRunner (excluding host and implicit dependencies) and format the output as a graph.
Then, paste the text into GraphViz.

When referencing targets within the same package, you can skip the package path and just use //:target-name. When referencing targets within the same BUILD file, you can even skip the // workspace root identifier and just use :target-name.
For example, for targets in the java-tutorial/BUILD file, you did not have to specify a package path, since the workspace root is itself a package (//), and your two target labels were simply //:ProjectRunner and //:greeter.
Fortunately, the java_binary rule allows you to build a self-contained, deployable binary. To build it, add the _deploy.jarsuffix to the file name when building runner.jar (_deploy.jar):
bazel build //src/main/java/com/example/cmdline:runner_deploy.jar





https://docs.bazel.build/versions/master/getting-started.html
export JAVA_HOME="$(dirname $(dirname $(realpath $(which javac))))"





Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts