Dış Bağımlılıklarla Çalışma

Sorun bildirinopen_in_new Kaynağı gösteropen_in_new

Bazel diğer projelerdeki hedeflere bağlı olabilir. Bu diğer projelerden kaynaklanan bağımlılıklara dış bağımlılıklar denir.

Çalışma alanı dizinindeki WORKSPACE dosyası (veya WORKSPACE.bazel dosyası), Bazel'e diğer projelerin kaynaklarını nasıl alacağını bildirir. Bu diğer projelerde, kendi hedefleri olan bir veya daha fazla BUILD dosyası bulunabilir. Ana projedeki BUILD dosyaları, WORKSPACE dosyasındaki adlarını kullanarak bu harici hedeflere bağlı olabilir.

Örneğin, bir sistemde iki proje olduğunu varsayalım:

/
  home/
    user/
      project1/
        WORKSPACE
        BUILD
        srcs/
          ...
      project2/
        WORKSPACE
        BUILD
        my-libs/

project1, /home/user/project2/BUILD içinde tanımlanan :foo hedefine bağımlı olmak isteseydi /home/user/project2 adresinde project2 adlı bir deponun bulunabileceğini belirtebilirdi. Daha sonra /home/user/project1/BUILD bölgesindeki hedefler @project2//:foo kaynağına bağlı olabilir.

WORKSPACE dosyası, kullanıcıların dosya sisteminin diğer bölümlerindeki veya internetten indirilen hedeflere bağlı olmasına olanak tanır. BUILD dosyalarıyla aynı söz dizimini kullanır ancak depo kuralları (bazen çalışma alanı kuralları olarak da bilinir) adı verilen farklı bir kural grubuna izin verir. Bazel, birkaç yerleşik depo kuralı ve bir dizi yerleşik Starlark deposu kuralı ile birlikte gelir. Kullanıcılar daha karmaşık davranışlar almak için özel depo kuralları da yazabilir.

Desteklenen harici bağımlılık türleri

Birkaç temel türde dış bağımlılık kullanılabilir:

• Diğer Bazel projelerine olan bağımlılıklar
• Bazel dışı projelere olan bağımlılıklar
• Harici paketlere olan bağımlılıklar

Diğer Bazel projelerine bağlı olarak

İkinci bir Bazel projesindeki hedefleri kullanmak istiyorsanız projeyi yerel dosya sisteminden sembolize etmek, git deposuna referans vermek veya indirmek için (sırasıyla local_repository, git_repository veya http_archive) kullanabilirsiniz.

Örneğin, my-project/ projesi üzerinde çalıştığınızı ve iş arkadaşınızın coworkers-project/ projesindeki hedeflere bağlı olarak çalışmak istediğinizi varsayalım. Her iki projede de Bazel kullanılır. Böylece iş arkadaşınızın projesini dış bağımlılık olarak ekleyebilir, ardından iş arkadaşınızın kendi DERLE dosyalarınızdan tanımladığı hedefleri kullanabilirsiniz. my_project/WORKSPACE öğesine aşağıdakileri eklersiniz:

local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
)

İş arkadaşınızın //foo:bar hedefi varsa projenizde bunu @coworkers_project//foo:bar olarak tanımlayabilirsiniz. Harici proje adları geçerli çalışma alanı adları olmalıdır.

Bazel dışı projelere bağlı olarak

Ön eki new_ olan new_local_repository gibi kurallar, Bazel kullanmayan projelerden hedefler oluşturmanıza olanak tanır.

Örneğin, my-project/ projesi üzerinde çalıştığınızı ve iş arkadaşınızın coworkers-project/ projesine bağlı kalmak istediğinizi varsayalım. İş arkadaşınızın projesi derleme için make kullanıyor, ancak siz onun oluşturduğu .so dosyalarından birini kullanmak istiyorsunuz. Bunu yapmak için my_project/WORKSPACE alanına aşağıdakileri ekleyin:

new_local_repository(
    name = "coworkers_project",
    path = "/path/to/coworkers-project",
    build_file = "coworker.BUILD",
)

build_file, mevcut projede yer paylaşımı için bir BUILD dosyası belirtir. Örneğin:

cc_library(
    name = "some-lib",
    srcs = glob(["**"]),
    visibility = ["//visibility:public"],
)

Sonrasında projenizin BUILD dosyalarında @coworkers_project//:some-lib uygulamasına güvenebilirsiniz.

Harici paketlere bağlı olarak

Maven yapıları ve depoları

Maven depolarından yapıları indirmek ve Java bağımlılığı olarak kullanılabilir hale getirmek için rules_jvm_external kural kümesini kullanın.

Bağımlılıkları getirme

Varsayılan olarak, bazel build sırasında harici bağımlılıklar gerektiğinde getirilir. Belirli bir hedef grubu için gereken bağımlılıkları önceden getirmek istiyorsanız bazel fetch işlevini kullanın. Tüm harici bağımlılıkları koşulsuz olarak getirmek için bazel sync işlevini kullanın. Getirilen depolar çıkış tabanında depolandığından, getirme işlemi çalışma alanı başına gerçekleşir.

Gölgelendirme bağımlılıkları

Mümkün olduğunda projenizde tek bir sürüm politikasına sahip olmanız önerilir. Bu, derlediğiniz ve son ikili dosyanıza dahil ettiğiniz bağımlılıklar için gereklidir. Ancak bunun doğru olmadığı durumlarda bağımlılıkları gölgede bırakmak mümkündür. Aşağıdaki senaryoyu değerlendirin:

projem/ÇALIŞMA ALANI

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/WORKSPACE

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

B/ÇALIŞMA ALANI

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

Hem A hem de B bağımlılıkları testrunner bağımlılığına bağlıdır, ancak testrunner farklı sürümlerine bağlıdır. Bu test koşucularının myproject içinde barış içinde bir arada var olmaması için bir neden yoktur, ancak aynı ada sahip oldukları için birbirleriyle çarpışacaklardır. Her iki bağımlılığı da bildirmek için myproject/WORKSPACE'i güncelleyin:

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

Bu mekanizma elmasları birleştirmek için de kullanılabilir. Örneğin A ve B aynı bağımlılığa sahipti ancak bunları farklı adlarla adlandırdıysa bu bağımlılıklar myproject/WORKSPACE'te birleştirilebilir.

Komut satırından depoları geçersiz kılma

Beyan edilen bir depoyu, komut satırından yerel kod deposuyla geçersiz kılmak için --override_repository işaretini kullanın. Bu işareti kullandığınızda, kaynak kodunuzu değiştirmeden harici depoların içeriği değiştirilir.

Örneğin, @foo öğesini /path/to/local/foo yerel dizinine geçersiz kılmak için --override_repository=foo=/path/to/local/foo işaretini iletin.

Kullanım alanlarından bazıları şunlardır:

• Hata ayıklama sorunları. Örneğin, http_archive deposunu yerel bir dizinde geçersiz kılabilir, böylece daha kolay değişiklik yapabilirsiniz.
• Tedarikçi firma. Ağ çağrıları yapamayacağınız bir ortamdaysanız bunun yerine ağ tabanlı depo kurallarını yerel dizinlere işaret edecek şekilde geçersiz kılın.

Proxy kullanma

Bazel, HTTPS_PROXY ve HTTP_PROXY ortam değişkenlerinden proxy adreslerini alır ve HTTP/HTTPS dosyalarını (belirtilmişse) indirmek için bunları kullanır.

IPv6 desteği

Yalnızca IPv6 kullanan makinelerde Bazel, bağımlılıkları hiçbir değişiklik yapmadan indirebilecek. Ancak Bazel, çift yığınlı IPv4/IPv6 makinelerinde Java ile aynı kuralı uygular: IPv4 etkinse IPv4 tercih edilir. Bazı durumlarda, örneğin IPv4 ağının harici adreslere çözümleyemediği veya bu adreslere ulaşamadığı durumlarda bu durum, Network unreachable istisnalarına ve derleme hatalarına neden olabilir. Böyle durumlarda java.net.preferIPv6Addresses=true sistem özelliğini kullanarak Bazel'in davranışını IPv6'yı tercih edecek şekilde geçersiz kılabilirsiniz. Özellikle:

• --host_jvm_args=-Djava.net.preferIPv6Addresses=true başlangıç seçeneğini kullanın. Örneğin .bazelrc dosyanıza aşağıdaki satırı ekleyin:

  startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

• İnternete de bağlanması gereken Java derleme hedefleri çalıştırıyorsanız (entegrasyon testleri bazen bunu gerektirir) --jvmopt=-Djava.net.preferIPv6Addresses=true araç işaretini de kullanın. Aşağıdaki satırı .bazelrc dosyanızda kullanabilirsiniz:

  build --jvmopt=-Djava.net.preferIPv6Addresses

• Örneğin, bağımlılık sürümü çözümlemesi için rules_jvm_external kullanıyorsanız Coursier için JVM seçenekleri sağlamak amacıyla COURSIER_OPTS ortam değişkenine -Djava.net.preferIPv6Addresses=true de ekleyin

Geçişli bağımlılıklar

Bazel, yalnızca WORKSPACE dosyanızda listelenen bağımlılıkları okur. Projeniz (A) WORKSPACE dosyasında üçüncü bir projeye (C) bağımlılığın listelendiği başka bir projeye (B) bağlıysa projenizin WORKSPACE dosyasına hem B hem de C eklemeniz gerekir. Bu koşul, WORKSPACE dosya boyutunu büyütebilir ancak bir kitaplığın 1.0 sürümünde C, 2.0'da C içermesi ihtimalini sınırlar.

Dış bağımlılıkları önbelleğe alma

Varsayılan olarak, Bazel yalnızca tanımları değişirse harici bağımlılıkları yeniden indirir. Tanımda başvurulan dosyalarda yapılan değişiklikler de (yamalar veya BUILD dosyaları gibi) bazel tarafından dikkate alınır.

Yeniden indirmeye zorlamak için bazel sync komutunu kullanın.

Düzen

Harici bağımlılıkların tümü, çıkış tabanındaki alt dizindeki external dizine indirilir. Yerel depo olması durumunda, yeni dizin oluşturmak yerine burada bir sembolik bağlantı oluşturulur. Aşağıdaki komutu çalıştırarak external dizinini görebilirsiniz:

ls $(bazel info output_base)/external

bazel clean çalıştırıldığında harici dizinin silinmeyeceğini unutmayın. Tüm harici yapıları kaldırmak için bazel clean --expunge işlevini kullanın.

Çevrimdışı derlemeler

Bazen bir derlemeyi çevrimdışı olarak çalıştırmak istenen veya gerekli olabilir. Uçakta seyahat etmek gibi basit kullanım alanları için bazel fetch veya bazel sync ile gerekli depoları önceden getirmek yeterli olabilir. Ayrıca, --nofetch seçeneği kullanıldığında daha fazla depo getirme işlemi, derleme sırasında devre dışı bırakılabilir.

Gerekli dosyaların bazel dışında bir varlık tarafından sağlandığı gerçek çevrimdışı derlemeler için bazel, --distdir seçeneğini destekler. Bir depo kuralı, bazel'dan ctx.download veya ctx.download_and_extract aracılığıyla bir dosya getirmesini istediğinde ve gereken dosyanın karma toplamını sağladığında, bazel önce sağlanan ilk URL'nin temel adıyla eşleşen bir dosya için bu seçenekle belirtilen dizinlere bakar ve karma dosya eşleşirse bu yerel kopyayı kullanır.

Bazel, dağıtım yapısından çevrimdışı önyükleme yapmak için bu tekniği kullanır. Bunu, gerekli tüm dış bağımlılıkları dahili distdir_tar içinde toplayarak yapar.

Ancak bazel, ağa çağrı yapıp yapmadıklarını bilmeden depo kurallarında rastgele komutların yürütülmesine olanak tanır. Bu nedenle, bazel'in derlemeleri tamamen çevrimdışı olmasını zorunlu kılma seçeneği yoktur. Bu nedenle, bir derlemenin çevrimdışı olarak çalışıp çalışmadığını test etmek, bazel'in önyükleme testinde yaptığı gibi, ağın harici olarak engellenmesini gerektirir.

En iyi uygulamalar

Depo kuralları

Bir depo kuralı genellikle şunlardan sorumlu olmalıdır:

• Sistem ayarlarını algılama ve dosyalara yazma.
• Sistemin başka bir yerinde kaynak bulma.
• Kaynaklar URL'lerden indiriliyor.
• Harici depo dizininde BUILD dosyası oluşturma veya bu dosyalara sembolik bağlama.

Mümkün olduğunda repository_ctx.execute kullanmaktan kaçının. Örneğin, Yapma kullanan bir derlemeye sahip Bazel olmayan C++ kitaplığını kullanırken ctx.execute(["make"]) çalıştırmak yerine repository_ctx.download() kullanılması ve ardından onu oluşturan bir BUILD dosyası yazılması tercih edilir.

git_repository ve new_git_repository yerine http_archive tercih edin. Nedenler şunlardır:

• Git deposu kuralları, git(1) sistemine bağlıdır. HTTP indirme aracı ise Bazel'de yerleşiktir ve herhangi bir sistem bağımlılığı yoktur.
• http_archive, ayna olarak urls listesini, git_repository ise yalnızca tek bir remote listesini destekler.
• http_archive, depo önbelleği ile çalışır ancak git_repository ile çalışmaz. Daha fazla bilgi için bkz. #5116.

bind() kullanmayın. Sorunları ve alternatifleri hakkında uzun bilgi için "Bağlantıyı kaldırmayı düşünün" bölümüne bakın.