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 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 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 olarakurls
listesini,git_repository
ise yalnızca listeyi destekler tek birremote
.http_archive
, depo önbelleği ile çalışır, ancakgit_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.