Çalışma Alanı Kuralları

Workspace kuralları, genellikle ana deponun dışında bulunan kaynak kodu gibi harici bağımlılıkları ç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 (özellikle web'de barındırılan Git depoları veya arşivlerle ilgili olanlar) yerleştirir.

Kurallar

• bind
• local_repository
• new_local_repository

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 ayrıntılı bilgi için "Bağlamayı kaldırmayı düşünün" bölümüne bakın. Özellikle repo_mapping depo özelliklerinin kullanımını göz önünde bulundurun.

Uyarı: select(), bind() içinde kullanılamaz. Ayrıntılı bilgi için Yapılandırılabilir Özellikler ile ilgili SSS başlıklı makaleyi inceleyin.

//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 bind dosyasında WORKSPACE'i kullanın. Örneğin, java_library adlı bir hedef olduğunu varsayalım.//third_party/javacc-v2 Aşağıdaki satırları WORKSPACE dosyasına ekleyerek bu komuta takma ad verebilirsiniz:

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

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

Bind, harici depolardaki hedefleri çalışma alanınızda kullanılabilir hale getirmek için de kullanılabilir. Örneğin, WORKSPACE dosyasında @my-ssl adlı bir uzak depo varsa ve bu deponun cc_library hedefi //src:openssl-lib ise bind kullanarak bu hedef için bir takma ad oluşturabilirsiniz:

bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

Daha sonra, ç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 kullanıma sunulan başlık dosyaları, depo köklerine göre yolları kullanılarak referans verilebilir. Örneğin, @my-ssl//src:openssl-lib için kural tanımı şu şekildeyse:

cc_library(
    name = "openssl-lib",
    srcs = ["openssl.cc"],
    hdrs = ["openssl.h"],
)

Bu durumda sign_in.cc'nın içerikleri şu şekilde görünebilir:

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

Bağımsız değişkenler

local_repository

local_repository(name, path, repo_mapping)

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

Örnekler

Mevcut deponun, ~/chat-app dizininde köklenmiş bir sohbet istemcisi olduğunu varsayalım. Bu depo, farklı bir depoda (~/ssl) tanımlanan bir SSL kitaplığını kullanmak istiyor. SSL kitaplığının hedefi //src:openssl-lib olmalıdır.

Kullanıcı, ~/chat-app/WORKSPACE dosyasına aşağıdaki satırları ekleyerek bu hedef için bağımlılık oluşturabilir:

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

Hedefler, bu kitaplığa bağlı olmak için @my-ssl//src:openssl-lib öğesini bağımlılık olarak belirtir.

Bağımsız değişkenler

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 olanak tanır. Bu, mevcut deponun, dosya sisteminin herhangi bir yerindeki hedefleri tanımlayabileceği ve kullanabileceği anlamına gelir.

Bu kural, WORKSPACE dosyası ve verilen BUILD dosyasına ve yola sembolik bağlantılar içeren bir alt dizin oluşturarak bir Bazel deposu oluşturur. Derleme dosyası, path ile ilgili hedefler oluşturmalıdır. WORKSPACE dosyası ve BUILD dosyası içeren dizinler için local_repository kuralı kullanılabilir.

Örnekler

Mevcut deponun, ~/chat-app dizininde köklenmiş bir sohbet istemcisi olduğunu varsayalım. Bu istemci, farklı bir dizinde (~/ssl) tanımlanan bir SSL kitaplığı kullanmak istiyor.

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

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

Ardından, aşağıdaki satırları ~/chat-app/WORKSPACE dosyası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ı oluşturulan bir @my-ssl deposu oluşturur. Hedefler, bir hedefin bağımlılıklarına @my-ssl//:openssl eklenerek bu kitaplığa bağlı olabilir.

Yalnızca dizinleri değil, tek dosyaları da eklemek için new_local_repository simgesini kullanabilirsiniz. Örneğin, /home/username/Downloads/piano.jar konumunda bir jar dosyanız olduğunu varsayalım. WORKSPACE dosyanıza aşağıdakileri ekleyerek yalnızca bu 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şturun:

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

Bağımsız değişkenler