Ç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.
Kurallar
bind
Kural kaynağını gösterbind(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 |
Bu hedef için benzersiz bir ad. |
actual
|
Bu hedefin mevcut olması gerekir ancak herhangi bir kural (bağlama dahil) olabilir. Bu özellik eklenmezse |
yerel_depo
Kural kaynağını gösterlocal_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 |
Bu hedef için benzersiz bir ad. |
path
|
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
|
Örneğin, bir giriş |
yeni_yerel_depo
Kural kaynağını gösternew_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 |
Bu hedef için benzersiz bir ad. |
build_file
|
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
|
build_file veya build_file_content belirtilmelidir. |
path
|
Bu, mutlak veya ana deponun WORKSPACE dosyasına göre olabilir. |
repo_mapping
|
Örneğin, bir giriş |
workspace_file
|
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
|
workspace_file veya workspace_file_content belirtilebilir ancak ikisi birden belirtilemez. |