Ç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.
Kurallar
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 |
Bu hedef için benzersiz bir ad. |
actual
|
Bu hedefin mevcut olması gerekir, ancak herhangi bir kural türü (bağlama dahil) olabilir. Bu özellik atlanırsa |
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 |
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öreli olabilir. |
repo_mapping
|
Örneğin, bir |
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 |
Bu hedef için benzersiz bir ad. |
build_file
|
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
|
build_file veya build_file_content belirtilmelidir. |
path
|
Bu, mutlak veya ana deponun WORKSPACE dosyasına göreli olabilir. |
repo_mapping
|
Örneğin, bir |
workspace_file
|
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
|
workspace_file veya workspace_file_content değerleri belirtilebilir, ancak ikisi birden belirtilemez. |