Çalışma Alanı Kuralları

Çalışma alanı kuralları, genellikle ana deposun dışında bulunan kaynak kodu olan harici bağımlılıkları almak için kullanılır.

Not: Bazel, yerel çalışma alanı kurallarının yanı sıra, özellikle git depoları veya web'de barındırılan arşivlerle ilgili olanlar olmak üzere çeşitli Starlark çalışma alanı kurallarını da yerleştirir.

Kurallar

• bind
• local_repository
• new_local_repository

bind

bind(name, actual, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, visibility)

Uyarı: bind() kullanılması önerilmez. Sorunları ve alternatifleri hakkında ayrıntılı bilgi için "bind işlevini kaldırmayı düşünün" bölümüne bakın. Özellikle repo_mapping depolama alanı özelliklerini kullanmayı düşünün.

Uyarı: select(), bind() içinde kullanılamaz. Ayrıntılar için Yapılandırılabilir Özellikler ile ilgili SSS başlıklı makaleyi inceleyin.

Bir hedefe //external paketinde bir takma ad verir.

//external paketi "normal" bir paket değildir: Harici/ dizin yoktur, bu nedenle tüm bağlı hedefleri içeren bir "sanal paket" olarak düşünülebilir.

Örnekler

Bir hedefe takma ad vermek için hedefi WORKSPACE dosyasında bind. Örneğin, //third_party/javacc-v2 adlı bir java_library hedefi olduğunu varsayalım. Aşağıdakiler WORKSPACE dosyasına eklenerek bu adla başka bir ad verilebilir:

bind(
    name = "javacc-latest",
    actual = "//third_party/javacc-v2",
)

Artık hedefler //third_party/javacc-v2 yerine //external:javacc-latest'e bağlı olabilir. javacc-v3 yayınlanırsa bind kuralı güncellenebilir ve //external:javacc-latest'e bağlı tüm BUILD dosyaları artık düzenlenmesine gerek kalmadan javacc-v3'e bağlı olur.

Bağlama, harici depolardaki hedefleri çalışma alanınızda kullanılabilir hale getirmek için de kullanılabilir. Örneğin, WORKSPACE dosyasına içe aktarılan @my-ssl adlı bir uzak depolama alanı varsa ve bu depolama alanında cc_library hedefi //src:openssl-lib varsa bind kullanarak bu hedef için bir takma ad oluşturabilirsiniz:

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

Ardından, çalışma alanınızdaki bir BUILD dosyasında bağlı hedef aşağıdaki gibi kullanılabilir:

cc_library(
    name = "sign-in",
    srcs = ["sign_in.cc"],
    hdrs = ["sign_in.h"],
    deps = ["//external:openssl"],
)

sign_in.cc ve sign_in.h içinde, //external:openssl tarafından sunulan üstbilgi dosyalarına, depo köklerine göreli yolları kullanılarak referans verilebilir. Örneğin, @my-ssl//src:openssl-lib için kural tanımı aşağıdaki gibiyse:

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

Bu durumda sign_in.cc'nin içeriği şöyle görünebilir:

#include "sign_in.h"
#include "src/openssl.h"

Bağımsız değişkenler

local_repository

local_repository(name, path, repo_mapping)

Yerel dizinlerdeki hedeflerin bağlanmasına izin verir. Bu, mevcut deponun bu diğer dizinde tanımlanan hedefleri kullanabileceği anlamına gelir. Daha fazla bilgi için bağlantı oluşturma bölümüne bakın.

Örnekler

Mevcut deponun, kökü ~/chat-app dizininde olan bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir depoda (~/ssl) tanımlanmış bir SSL kitaplığı kullanmak istiyor. SSL kitaplığında bir hedef //src:openssl-lib var.

Kullanıcı, aşağıdaki satırları ~/chat-app/WORKSPACE bölümüne ekleyerek bu hedefe bağımlılık ekleyebilir:

local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
)

Hedefler, bu kitaplığa bağımlı olacak bir bağımlılık olarak @my-ssl//src:openssl-lib'ü belirtir.

Bağımsız değişkenler

new_local_repository

new_local_repository(name, build_file, build_file_content, path, repo_mapping, workspace_file, workspace_file_content)

Yerel bir dizinin Bazel deposuna dönüştürülmesine olanak tanır. Bu, mevcut deponun dosya sisteminde herhangi bir yerden hedefleri tanımlayıp kullanabileceği anlamına gelir.

Bu kural, WORKSPACE dosyası ve verilen BUILD dosyasına ve yola yönelik simge bağlantıları içeren bir alt dizin oluşturarak bir Bazel deposu oluşturur. Derleme dosyası, path ile ilgili hedefler oluşturmalıdır. Halihazırda bir WORKSPACE dosyası ve BUILD dosyası içeren dizinler için local_repository kuralı kullanılabilir.

Örnekler

Mevcut deponun, kökü ~/chat-app dizininde olan bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir dizinde (~/ssl) tanımlanmış bir SSL kitaplığı kullanmak istiyor.

Kullanıcı, SSL kitaplığı için aşağıdakileri içeren bir BUILD dosyası (~/chat-app/BUILD.my-ssl) oluşturarak bağımlılık ekleyebilir:

java_library(
    name = "openssl",
    srcs = glob(['*.java'])
    visibility = ["//visibility:public"],
)

Ardından, şu satırları ~/chat-app/WORKSPACE alanına ekleyebilirler:

new_local_repository(
    name = "my-ssl",
    path = "/home/user/ssl",
    build_file = "BUILD.my-ssl",
)

Bu işlem, /home/user/ssl adresine simge bağlantısı veren bir @my-ssl deposu oluşturur. Hedefler, hedefin bağımlılıklarına @my-ssl//:openssl ekleyerek bu kitaplığa bağımlı olabilir.

Yalnızca dizinleri değil, tek dosyaları da dahil etmek için new_local_repository simgesini kullanabilirsiniz. Örneğin, /home/kullanıcıadı/Downloads/piano.jar adresinde bir jar dosyanız olduğunu varsayalım. WORKSPACE dosyanıza aşağıdakileri ekleyerek yalnızca bu dosyayı derlemenize ekleyebilirsiniz:

new_local_repository(
    name = "piano",
    path = "/home/username/Downloads/piano.jar",
    build_file = "BUILD.piano",
)

Aşağıdaki BUILD.piano dosyasını oluşturun:

java_import(
    name = "play-music",
    jars = ["piano.jar"],
    visibility = ["//visibility:public"],
)

Bağımsız değişkenler