Bu sayfa, Cloud Translation API ile çevrilmiştir.

Çalışma Alanı Kuralları

Çalışma alanı kuralları, harici bağımlılıkları (genellikle ana deponun dışında bulunan kaynak kodu) çekmek için kullanılır.

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

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 uzun bir açıklama için "Bağlantıyı kaldırmayı düşünün" bölümüne bakın. Özellikle repo_mapping deposu özelliklerini kullanmayı düşünün.

Uyarı: select(), bind() içinde kullanılamaz. Ayrıntılar için Yapılandırılabilir Özellikler ile İlgili SSS bölümünü inceleyin.

//external paketinde bir hedefe takma ad verir.

//external paketi "normal" bir paket değil: 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 WORKSPACE dosyasında bu hedefi bind. Örneğin, //third_party/javacc-v2 adında bir java_library hedefi olduğunu varsayalım. WORKSPACE dosyasına aşağıdaki dosya eklenerek diğer ad verilebilir:

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

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

Bağlama özelliği, harici depolardaki hedefleri çalışma alanınızın kullanımına sunmak için de kullanılabilir. Örneğin, WORKSPACE dosyasına içe aktarılmış @my-ssl adlı bir uzak depo varsa ve //src:openssl-lib cc_library hedefine sahipse bind kullanarak bu hedef için 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 üst bilgi dosyalarına, depo köklerine göre yol 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 öğeleri aşağıdaki gibi görünebilir:

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

Bağımsız değişkenler

Özellikler

name

Name; required

Bu hedef için benzersiz bir ad.

actual

Label; optional

Takma ad verilecek hedef.

Bu hedef mevcut olmalıdır ancak herhangi bir kural türünde (bağlama dahil) olabilir.

Bu özellik atlanırsa //external içinde bu hedefe işaret eden kurallar bu bağımlılık sınırını görmez. Bunun, bind kuralının tamamen atlanmasından farklı olduğunu unutmayın: //external bağımlılığının ilişkili bir bind kuralı yoksa bu bir hatadır.

local_repository

local_repository(name, path, repo_mapping)

Yerel dizindeki hedeflerin bağlanmasına izin verir. Bu, geçerli deponun bu diğer dizinde tanımlanan hedefleri kullanabileceği anlamına gelir. Daha ayrıntılı bilgi için bağlama bölümüne bakın.

Örnekler

Mevcut deponun, rootlanmış ~/chat-app dizininde bulunan bir sohbet istemcisi olduğunu varsayalım. Bu depo, farklı bir depoda tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl. SSL kitaplığında bir hedef //src:openssl-lib bulunur.

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

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

Hedefler, bu kitaplığa bağımlı olarak @my-ssl//src:openssl-lib değerini belirtir.

Bağımsız değişkenler

Özellikler

name

Name; required

Bu hedef için benzersiz bir ad.

path

String; required

Yerel kod deposunun dizini yolu.

Bu, deponun WORKSPACE dosyasını içeren dizine giden bir yol olmalıdır. Yol, mutlak veya ana deponun WORKSPACE dosyasına göreli olabilir.

repo_mapping

Dictionary: String -> String; optional

Yerel kod deposu adından genel kod deposu adına bir sözlük. Böylece bu deponun bağımlılıkları için çalışma alanı bağımlılık çözümü üzerinde kontrol sahibi olursunuz.

Örneğin, bir "@foo": "@bar" girişi bu deponun "@foo" ürününe bağlı olduğu her zaman ("@foo//some:target" üzerindeki bir bağımlılık gibi) söz konusu bağımlılığı global olarak tanımlanan "@bar" ("@bar//some:target") içinde çözmesi gerektiğini bildirir.

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 izin verir. Bu, geçerli deponun dosya sisteminde herhangi bir yerden hedef tanımlayıp kullanabileceği anlamına gelir.

Bu kural, WORKSPACE dosyası ile BUILD dosyasının sembolik bağlantılarını ve belirtilen yolu içeren alt dizin oluşturarak bir Bazel deposu oluşturur. Derleme dosyası, path ile göreli hedefler oluşturmalıdır. Halihazırda WORKSPACE dosyası ve BUILD dosyası içeren dizinler için local_repository kuralı kullanılabilir.

Örnekler

Mevcut deponun, rootlanmış ~/chat-app dizininde bulunan bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir dizinde tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl.

Kullanıcı, SSL kitaplığı (~/chat-app/BUILD.my-ssl) için şunları içeren bir BUILD dosyası 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 ile sembolik bağlantı kuran bir @my-ssl deposu oluşturur. Hedefler, hedefin bağımlılıklarına @my-ssl//:openssl ekleyerek bu kitaplığa bağlı olabilir.

Yalnızca dizinleri değil, tek tek dosyaları eklemek için de new_local_repository kullanabilirsiniz. Örneğin, /home/username/Downloads/piano.jar konumunda bir jar dosyanızın olduğunu varsayalım. WORKSPACE dosyanıza aşağıdakileri ekleyerek sadece bu dosyayı derlemenize ekleyebilirsiniz:

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

Ayrıca aşağıdaki BUILD.piano dosyasını oluşturarak:

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

Bu durumda hedefler, piano.jar'ı kullanmak için @piano//:play-music hizmetine bağlı olabilir.

Bağımsız değişkenler

Özellikler
`name`	`Name; required` Bu hedef için benzersiz bir ad.
`build_file`	`String; optional` Bu dizin için DERLEME dosyası olarak kullanılacak bir dosya. build_file veya build_file_content belirtilmelidir. Bu özellik, ana çalışma alanıyla göreli bir etikettir. Dosyanın BUILD olarak adlandırılması gerekmez, ancak adlandırılmış olabilir. (BUILD.new-repo-name gibi bir işlev, dosyayı deponun gerçek DERLEME dosyalarından ayırt etmek için işe yarayabilir.)
`build_file_content`	`String; optional` Bu kod deposu için DERLEME dosyasının içeriği. build_file veya build_file_content belirtilmelidir.
`path`	`String; required` Yerel dosya sistemindeki bir yol. Bu değer, mutlak veya ana deponun WORKSPACE dosyasıyla göreli olabilir.
`repo_mapping`	`Dictionary: String -> String; optional` Yerel kod deposu adından genel kod deposu adına bir sözlük. Böylece bu deponun bağımlılıkları için çalışma alanı bağımlılık çözümü üzerinde kontrol sahibi olursunuz. Örneğin, bir `"@foo": "@bar"` girişi bu deponun `"@foo"` ürününe bağlı olduğu her zaman (`"@foo//some:target"` üzerindeki bir bağımlılık gibi) söz konusu bağımlılığı global olarak tanımlanan `"@bar"` (`"@bar//some:target"`) içinde çözmesi gerektiğini bildirir.
`workspace_file`	`String; optional` Bu kod deposu için WORKSPACE dosyası olarak kullanılacak dosya. workspace_file ve workspace_file_content değerleri belirtilebilir ancak ikisi birden belirtilemez. Bu özellik, ana çalışma alanıyla göreli bir etikettir. Dosyanın WORKSPACE olarak adlandırılması gerekmez ancak adlandırılmış olabilir. (WORKSPACE.new-repo-name kodu, deponun gerçek WORKSPACE dosyalarından ayırt edilmesi için kullanışlıdır.)
`workspace_file_content`	`String; optional` Bu kod deposundaki WORKSPACE dosyasının içeriği. workspace_file ve workspace_file_content değerleri belirtilebilir ancak ikisi birden belirtilemez.