Kararlı sürüm dokümanları için lütfen "Sürümlü dokümanlar" açılır listesini kullanın. Varsayılan görünüm HEAD adresindeki en son sürümü yansıtır.

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

Çalışma Alanı Kuralları

Sorun bildirin Kaynağı göster

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

Not: Yerel çalışma alanı kurallarının yanı sıra Bazel, özellikle web'de barındırılan git depolarıyla veya arşivlerle ilgilenmeleri için çeşitli Starlark çalışma alanı kuralları da yerleştirir.

bind

Kural kaynağını göster

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 tartışma için "Bağlamayı kaldırma konusunu inceleyin" bölümüne bakın. Özellikle repo_mapping deposu özellikleri kullanmayı değerlendirin.

Uyarı: select(), bind() içinde kullanılamaz. Ayrıntılar için Yapılandırılabilir Özellikler Hakkında SSS bölümüne bakın.

//external paketinde bir hedefe takma ad verir.

//external paketi "normal" bir paket olmadığı için harici/ dizine dahil değildir. Bu nedenle, tüm bağlı hedefleri içeren bir "sanal paket" olarak düşünebilirsiniz.

Örnekler

Hedefe takma ad vermek için WORKSPACE dosyasında takma ada bind ekleyin. Örneğin, //third_party/javacc-v2 adında bir java_library hedefi olduğunu varsayalım. Aşağıdaki adlar, WORKSPACE dosyasına aşağıdaki adla eklenebilir:

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

Artık hedefler //third_party/javacc-v2 yerine //external:javacc-latest özelliğini kullanabilir. javacc-v3 yayınlanırsa bind kuralı güncellenebilir ve //external:javacc-latest adresine bağlı tüm BUILD dosyaları artık düzenlenmesine gerek kalmadan javacc-v3'ü temel alır.

Bağlama işlemi, harici depolardaki hedefleri çalışma alanınıza sunmak için de kullanılabilir. Örneğin, WORKSPACE dosyasında içe aktarılan @my-ssl adında uzak bir depo varsa ve cc_library hedefi //src:openssl-lib ise 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 DERLE 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 açığa çıkarılan başlık dosyaları, kendi yollarında kod deposu köklerine göre başvurulabilir. Ö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"],
)

sign_in.cc adlı ürünün içeriği şu şekilde 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

Diğer adı olan hedef.

Bu hedefin mevcut olması gerekir ancak herhangi bir kural (bağlama dahil) olabilir.

Bu özellik eklenmezse //external içerisinde bu hedefe referans veren kurallar bu bağımlılık kenarını görmez. Bunun, bind kuralını atlamaktan farklı olduğunu unutmayın: //external bağımlılığının ilişkili bir bind kuralı yoksa bu bir hatadır.

yerel_depo

Kural kaynağını göster

local_repository(name, path, repo_mapping)

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

Örnekler

Mevcut deponun, ~/chat-app dizinine rootlanmış bir sohbet istemcisi olduğunu varsayalım. İstemci, farklı bir depoda tanımlı bir SSL kitaplığı kullanmak istiyor: ~/ssl. SSL kitaplığının hedef //src:openssl-lib öğesi var.

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

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

Hedefler, @my-ssl//src:openssl-lib özelliğini bu kitaplığa bağımlı olan bir bağımlılık olarak belirtir.

Bağımsız değişkenler

Özellikler

name

Name; required

Bu hedef için benzersiz bir ad.

path

String; required

Yerel depo dizininin yolu.

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

repo_mapping

Dictionary: String -> String; optional

Yerel kod deposu adından genel depo adına bir sözlük. Bu, bu deponun bağımlılıkları için çalışma alanı bağımlılığı denetimine olanak tanır.

Örneğin, bir giriş "@foo": "@bar" bu deponun "@foo" bağımlılığına ("@foo//some:target" bağımlılığı gibi) yönelik her zaman, dünya genelinde beyan edilen "@bar" ("@bar//some:target") içindeki bu bağımlılığı çözmesi gerektiğini beyan eder.

yeni_yerel_depo

Kural kaynağını göster

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

Yerel dizinin Bazel veri havuzuna dönüştürülmesini sağlar. Yani mevcut kod deposu, dosya sisteminin herhangi bir yerindeki hedefleri tanımlayabilir ve kullanabilir.

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

Örnekler

Mevcut deponun, ~/chat-app dizinine dayanan bir sohbet istemcisi olduğunu varsayalım. Farklı bir dizinde tanımlı bir SSL kitaplığı kullanmak istiyor: ~/ssl.

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

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

Ardından ~/chat-app/WORKSPACE'e aşağıdaki satırları ekleyebilirler:

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

Bu işlem, /home/kullanıcı/ssl simgesine benzeyen bir @my-ssl deposu oluşturur. Hedefler, bir hedefin bağımlılarına @my-ssl//:openssl ekleyerek bu kitaplığa bağlı olabilir.

Ayrıca, yalnızca dizinleri değil, tek dosyaları da dahil etmek için new_local_repository özelliğini kullanabilirsiniz. Örneğin, /home/kullanıcıadı/Downloads/piano.jar sayfasında bir jar dosyanız olduğunu varsayalım. WORKSPACE dosyanıza aşağıdakileri ekleyerek yalnızca söz konusu 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şturma:

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

Sonra, hedefler piano.jar kullanımını @piano//:play-music ile sürdürebilir.

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 DERLE dosyası olarak kullanılacak bir dosya. build_file veya build_file_content belirtilmelidir. Bu özellik, ana çalışma alanına göre oluşturulan bir etikettir. Dosya, DERLE olarak adlandırılmış olması gerekmez, ancak adlandırılabilir. (buildscript.new-repo-name-adlı bir komut dosyası, bu depoyu gerçek BUILD dosyalarından ayırmak için iyi çalışabilir.)
`build_file_content`	`String; optional` Bu depoya ilişkin DERLE dosyasının içeriği. build_file veya build_file_content belirtilmelidir.
`path`	`String; required` Yerel dosya sistemindeki bir yol. Bu, mutlak veya ana deponun WORKSPACE dosyasına göre olabilir.
`repo_mapping`	`Dictionary: String -> String; optional` Yerel kod deposu adından genel depo adına bir sözlük. Bu, bu deponun bağımlılıkları için çalışma alanı bağımlılığı denetimine olanak tanır. Örneğin, bir giriş `"@foo": "@bar"` bu deponun `"@foo"` bağımlılığına (`"@foo//some:target"` bağımlılığı gibi) yönelik her zaman, dünya genelinde beyan edilen `"@bar"` (`"@bar//some:target"`) içindeki bu bağımlılığı çözmesi gerektiğini beyan eder.
`workspace_file`	`String; optional` Bu depo için WORKSPACE dosyası olarak kullanılacak dosya. workspace_file veya workspace_file_content belirtilebilir ancak ikisi birden belirtilemez. Bu özellik, ana çalışma alanına göre oluşturulan bir etikettir. Dosyaya WORKSPACE şeklinde ad verilmesi gerekmez ancak ad olabilir. (WORKSPACE.yeni-depo-adı gibi bir özellik, bu adı deponun gerçek WORKSPACE dosyalarından ayırmak için iyi çalışabilir.)
`workspace_file_content`	`String; optional` Bu depoya ait WORKSPACE dosyasının içeriği. workspace_file veya workspace_file_content belirtilebilir ancak ikisi birden belirtilemez.