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 çeşitli Starlark çalışma alanı kurallarını da yerleştirir. Bu kurallar, özellikle web'de barındırılan git depoları veya arşivlerle ilgilenmek için kullanılır.

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 Özelliklerle İlgili SSS bölümüne bakın.

//external paketinde bir hedefe 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 WORKSPACE dosyasında bu takma adı bind kullanın. Örneğin, //third_party/javacc-v2 adında bir java_library hedefi olduğunu varsayalım. WORKSPACE dosyasına aşağıdaki dosya eklenerek bu alan takma 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 paketine bağlı tüm DERLEME dosyaları, düzenleme yapılmasına gerek kalmadan javacc-v3'e bağımlı olur.

Bind, 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ılan @my-ssl adlı bir uzak depo varsa ve //src:openssl-lib cc_library hedefine sahipse bind öğesini 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 gösterilen üst bilgi dosyalarına, depo köklerine göre kendi yollarının kullanıldığı belirtilebilir. Örneğin, @my-ssl//src:openssl-lib kural tanımı şunun gibi görünüyorsa:

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

Diğer adı verilecek hedef.

Bu hedefin mevcut olması gerekir, ancak herhangi bir kural türü (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şkilendirilmiş bir bind kuralı yoksa hata oluşur.

local_repository

local_repository(name, path, repo_mapping)

Yerel dizindeki hedeflerin sınırlanmasına izin verir. Yani geçerli depo, bu diğer dizinde tanımlanan hedefleri kullanabilir. Daha ayrıntılı bilgi için bağlama bölümünü inceleyin.

Örnekler

Geçerli deponun, rootlanmış bir sohbet istemcisi olan ~/chat-app olduğunu varsayalım. 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 hedefine 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ı olmak için @my-ssl//src:openssl-lib değerini 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ö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" öğesine bağlı olduğu her durumda ("@foo//some:target" üzerindeki bağımlılık gibi) bu bağımlılığı, küresel 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 dizinin Bazel deposuna dönüştürülmesine izin verir. Bu, geçerli kod deposunun dosya sisteminde herhangi bir yerde hedefler tanımlayıp kullanabileceği anlamına gelir.

Bu kural, WORKSPACE dosyası ile BUILD dosyasına ve verilen yol için sembolik bağlantıları 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 ve BUILD dosyası içeren dizinler için local_repository kuralı kullanılabilir.

Örnekler

Mevcut kod deposunun, rootlanmış bir sohbet istemcisi olan ~/chat-app olduğunu varsayalım. Farklı bir dizinde tanımlanmış bir SSL kitaplığı kullanmak istiyor: ~/ssl.

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

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

Ardından ~/chat-app/WORKSPACE alanına şu satırları 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ı oluşturan 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 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 derlemenize sadece bu dosyayı ekleyebilirsiniz:

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

Ayrıca şu BUILD.piano dosyasını oluşturun:

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

Bu durumda hedefler, piano.jar'ı kullanmak için @piano//:play-music'ye 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 adlı bir ad olması gerekmez, ancak ad verilebilir. (BUILD.new-repo-name gibi bir kod, kod deposunun gerçek BUILD dosyalarından ayırt edilmesi için işe yarayabilir.)
`build_file_content`	`String; optional` Bu kod deposu için BUILD 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ö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"` öğesine bağlı olduğu her durumda (`"@foo//some:target"` üzerindeki bağımlılık gibi) bu bağımlılığı, küresel 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 veya workspace_file_content değerleri belirtilebilir, ancak ikisi birden belirtilemez. Bu özellik, ana çalışma alanıyla göreli bir etikettir. Dosya, WORKSPACE olarak adlandırılmak zorunda değildir ancak adlandırılabilir. (WORKSPACE.new-repo-name gibi bir kod, kod deposunun gerçek WORKSPACE dosyalarından ayırt edilmesi için kullanışlıdır.)
`workspace_file_content`	`String; optional` Bu kod deposu için WORKSPACE dosyasının içeriği. workspace_file veya workspace_file_content değerleri belirtilebilir, ancak ikisi birden belirtilemez.