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

. Sorun bildirin Kaynağı göster Gece · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Bazel diğer projelerdeki hedeflere bağlı olabilir. Diğer bağımlılıklara projelere dış bağımlılıklar denir.

WORKSPACE dosyası (veya WORKSPACE.bazel dosyası), workspace dizini Bazel’a diğer projeleri nasıl edineceğini anlatır. kaynaklar. Bu diğer projeler kendi hedeflerine sahip bir veya daha fazla BUILD dosyası içeren. BUILD dosya temel proje, hedeflerin adlarını kullanarak bu harici hedeflere bağlı olabilir. WORKSPACE dosyası.

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

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

project1 bir hedefe bağlı kalmak isterse :foo /home/user/project2/BUILD adlı dosya, project2, /home/user/project2 adresinde bulundu. Daha sonra /home/user/project1/BUILD, @project2//:foo metriğine bağlı olabilir.

WORKSPACE dosyası, kullanıcıların Google Cloud'un diğer bölümlerindeki ya da internetten indirebileceğiniz anlamına gelir. BUILD ile aynı söz dizimini kullanır dosyalarına erişebilir, ancak depo kuralları adı verilen farklı bir kural grubuna izin verir (bazen çalışma alanı kuralları olarak da bilinir). Bazel, yerleşik birkaç kod deposu ile birlikte gelir kuralları ve bir dizi yerleştirilmiş Starlark deposu kuralları hakkında daha fazla bilgi edinin. Kullanıcılar ayrıca özel depo kurallarını kullanın.

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

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

Diğer Bazel projelerine bağlı olarak

İkinci bir Bazel projesindeki hedefleri kullanmak isterseniz kullan local_repository git_repository veya http_archive yerel dosya sisteminden sembolik bağlamak için, bir git deposuna referans verin veya tıklayın (sırasıyla).

Örneğin, my-project/ adlı bir proje üzerinde çalıştığınızı ve iş arkadaşınızın projesindeki (coworkers-project/) hedeflere bağlı olarak değişiyor. Her ikisi Bazel'ı kullanır, böylece iş arkadaşınızın projesini harici bir e-tablo olarak ve iş arkadaşınızın kendi özel hedeflerinden yola çıkarak belirlediği hedefleri kullanın. Dosya derleyin. my_project/WORKSPACE öğesine aşağıdakileri eklersiniz:

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

İş arkadaşınızın bir hedef //foo:bar varsa projenizde bunu @coworkers_project//foo:bar. Harici proje adları şöyle olmalıdır: geçerli çalışma alanı adlarını kullanın.

Bazel dışı projelere bağlı olarak

new_ önekli kurallar, örneğin new_local_repository, Bazel kullanmayan projelerden hedef oluşturmanıza olanak tanır.

Örneğin, my-project/ adlı bir proje üzerinde çalıştığınızı ve iş arkadaşınızın projesine (coworkers-project/) bağlı olarak. İş arkadaşınızın projesi derleme için make kullanıyor, ancak siz .so dosyalarından birini kullanmak istiyorsunuz yardımcı olur. 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 kullanılacak bir BUILD dosyası belirtir örnek:

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

Sonrasında projenizin kendi bütçesinden @coworkers_project//:some-lib BUILD dosya.

Harici paketlere bağlı olarak

Maven yapıları ve depoları

rules_jvm_external kural kümesini kullanma Maven depolarındaki yapıları indirme ve bunları Java olarak kullanılabilir hale getirme ve bildirmeyi konuştuk.

Bağımlılıkları getirme

Varsayılan olarak, bazel build sırasında harici bağımlılıklar gerektiğinde getirilir. Eğer belirli bir hedef grubu için gereken bağımlılıkları önceden getirmek istiyorsanız bazel fetch. Tüm dış bağımlılıkları koşulsuz olarak getirmek için bazel sync. Getirilen depolar çıkış tabanında depolandığından, gerçekleşebilir.

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

Mümkün olduğunda, belirler. Bu, derleme yaptığınız ve sonunda elde ettiğiniz bağımlılıklar için gereklidir. son ikili dosyanıza ekleyin. Ancak bunun doğru olmadığı durumlarda, gölge bağımlılıkları hakkında bilgi edindiniz. 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/ÇALIŞMA ALANI

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 = "..."
)

A ve B bağımlılarının ikisi de testrunner bağımlılığıdır, ancak şuna bağlıdır: testrunner için farklı sürümler. Bu test çalıştırıcılarının myproject içinde barış içinde bir arada bulunamaz, ancak her biriyle çatışacak çünkü aynı isimlere sahipler. Her iki bağımlılığı da tanımlamak için projemi/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 sahip olduğunu ama onu farklı adlarla adlandırdığını varsayalım. Bu bağımlılıklar myproject/WORKSPACE'e katılın.

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

Komut satırından, bildirilen depoyu yerel bir depoyla geçersiz kılmak için: her bir arama terimi için --override_repository tıklayın. Bu işaretin kullanılması harici depoların içeriğini değiştirir: kaynak kodunuzu değiştirebilirsiniz.

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

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

  • Hata ayıklama sorunları. Örneğin, http_archive deposunu geçersiz kılabilirsiniz. değişiklikleri daha kolay yapabileceğiniz yerel bir dizine ekleyebilirsiniz.
  • Tedarikçi firma. Ağ çağrıları yapamayacağınız bir ortamdaysanız Ağ tabanlı depo kurallarını yerel dizinlere işaret edecek şekilde geçersiz kıl .

Proxy kullanma

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

IPv6 desteği

Yalnızca IPv6 kullanan makinelerde Bazel, bağımlılıkları değişiklik yok. Ancak Bazel, çift yığınlı IPv4/IPv6 makinelerinde aynı normaldir: IPv4 etkinse IPv4 tercih edilir. Bazı durumlarda, Örneğin IPv4 ağının harici adreslere çözümlemesi/ulaşması mümkün olmadığında, bu, Network unreachable istisnalarına ve derleme hatalarına neden olabilir. Bu durumlarda, IPv6'yı tercih etmek için Bazel'in davranışını geçersiz kılabilirsiniz. java.net.preferIPv6Addresses=true sistem özelliğini kullanarak. Özellikle:

  • --host_jvm_args=-Djava.net.preferIPv6Addresses=true hesabını kullan başlangıç seçeneğini kullanıyorsanız Örneğin, .bazelrc dosyası:

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

  • İnternete bağlanması gereken Java derleme hedefleri çalıştırıyorsanız gerekir (entegrasyon testleri bazen bunu gerektirir), --jvmopt=-Djava.net.preferIPv6Addresses=true. araç işaretini kullanabilir, örneğin .bazelrc dosyanızda şu satırı ekleyin:

    build --jvmopt=-Djava.net.preferIPv6Addresses

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

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

Bazel, yalnızca WORKSPACE dosyanızda listelenen bağımlılıkları okur. Projeniz (A), üçüncü bir projeye bağımlılığın listelendiği başka bir projeye (B) bağlı projesi (C) için WORKSPACE dosyasında her iki B ve C dosyalarını projenizin WORKSPACE dosyasına ekleyin. Bu gereklilik, şirket içinde Dosya boyutu WORKSPACE, ancak tek kitaplık oluşturma şansınız var 1.0 sürümünde C içerir ve bir diğeri 2.0 sürümünde C içerir.

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

Varsayılan olarak, Bazel yalnızca tanım değişikliklerinden söz edebiliriz. Tanımda başvurulan dosyalarda yapılan değişiklikler (yamalar gibi) veya BUILD dosyası) bazel tarafından da dikkate alınır.

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

Düzen

Harici bağımlılıkların tümü, alt dizin altındaki bir dizine indirilir. Çıkış tabanında external bulunur. Böyle bir durumda local repository, bir sembolik bağlantı oluşturulur oradan da yükleyebilirsiniz. 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 dizin. 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. Örneğin, basit kullanım alanları (ör. uçakta seyahat, prefetching bazel fetch veya bazel sync içeren depolar yeterli olabilir; bunun yanı sıra --nofetch seçeneği kullanıldığında, daha fazla deponun getirilmesi devre dışı bırakılabilir yardımcı oluyorum.

Gerekli dosyaların sağlandığı gerçek çevrimdışı derlemeler için başka bir tüzel kişi tarafından oluşturulduğunda, bazel --distdir Bir depo kuralı, bazel'dan ctx.download veya ctx.download_and_extract ve dosyanın karma toplamını sağlar gerekiyorsa bazel, ilk olarak sağlanan ilk URL'nin temel adıyla eşleşen bir dosya ve bu yerel kopyayı değeri gösterilir.

Bazel, bu tekniği kullanarak dağıtım test eder. Bunu, gerekli tüm harici verileri toplayarak bağımlılıkları dahili distdir_tar.

Ancak bazel, kod deposu kurallarında rastgele komutların yürütülmesine izin verir. bilmeden çalışır. Bu nedenle, bazel için derlemelerin tamamen çevrimdışı olmasını sağlamak için kullanılır. Bir derlemenin doğru çalışıp çalışmadığını test etmek için çevrimdışı erişim için ağın harici olarak engellenmesi gerekir. testi.

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, Bazel C++ oluşturma kullanan bir derleme varsa repository_ctx.download() ve ardından ctx.execute(["make"]) komutunu çalıştırmak yerine onu oluşturan bir BUILD dosyası yazma

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

  • Git deposu kuralları, git(1) sistemine bağlıdır ancak HTTP indirme aracı derlenmiştir hiçbir sistem bağımlılığı yoktur.
  • http_archive, ayna olarak urls listesini, git_repository ise yalnızca listeyi destekler tek bir remote.
  • http_archive, depo önbelleği ile çalışır, ancak git_repository. Görüntüleyin Daha fazla bilgi için #5116.

bind() kullanmayın. Daha fazla bilgi için "Kaldırmayı bağla" uzun süreyle ve alternatifleri üzerine konuşacağız.