Genel Kurallar

Sorun bildirin Kaynağı göster

Kurallar

takma ad

Kural kaynağını göster
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias kuralı, kurala ad verilebilecek başka bir ad oluşturur.

Takma ad oluşturma yalnızca "normal" hedefler için çalışır. Özellikle, package_group ve test_suite için diğer ad kullanılamaz.

Takma ad oluşturma, bir hedefi yeniden adlandırmak için çok sayıda dosya üzerinde değişiklik yapılmasının gerektiği büyük depolarda yardımcı olabilir. Takma ad kuralını birden fazla hedef için yeniden kullanmak istiyorsanız select işlev çağrısını depolamak için de kullanabilirsiniz.

Takma ad kuralının kendi görünürlük bildirimi vardır. Diğer tüm açılardan bakıldığında, bazı küçük istisnalarla birlikte, referansta bulunduğu kural gibi davranır (ör. takma adda test amaçlı yoksayılır; bunun yerine, referans verilen kuralın test amaçlı kullanımı kullanılır) ancak bazı küçük istisnalar söz konusudur:

  • Komut satırında takma adından bahsedilirse testler çalıştırılmaz. Başvuruda bulunulan testi çalıştıran bir takma ad tanımlamak için tests özelliğinde tek hedef bulunan bir test_suite kuralı kullanın.
  • Ortam grupları tanımlanırken environment kurallarının takma adları desteklenmez. Bunlar, --target_environment komut satırı seçeneğinde de desteklenmez.

Örnekler

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.

actual

Label; zorunlu

Bu takma adın belirttiği hedef. Kural olması gerekmez, giriş dosyası da olabilir.

config_setting

Kural kaynağını göster
config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

Yapılandırılabilir özelliklerin tetiklenmesi amacıyla, beklenen bir yapılandırma durumuyla (derleme işaretleri veya platform kısıtlamaları olarak ifade edilir) eşleşir. Bu kuralın nasıl kullanılacağı ile ilgili bilgi için select (Seçme) bölümüne ve genel özelliğe genel bakış için Yapılandırılabilir özellikler bölümüne bakın.

Örnekler

Aşağıdaki, --compilation_mode=opt veya -c opt değerini ayarlayan herhangi bir derlemeyle eşleşir (açıkça komut satırında veya dolaylı olarak .bazelrc dosyalarından):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

Aşağıdaki, ARM'yi hedefleyen ve özel FOO=bar tanımlamasını uygulayan herhangi bir derlemeyle eşleşir (örneğin, bazel build --cpu=arm --define FOO=bar ...):

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

Aşağıdaki, kullanıcı tanımlı işareti --//custom_flags:foo=1 (açıkça komut satırında veya dolaylı olarak .bazelrc dosyalarından) ayarlayan her derlemeyle eşleşir:

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

Aşağıdaki örnek, x86_64 mimarisine ve glibc sürüm 2.25'e sahip bir platformu hedefleyen tüm derlemelerle eşleşir ve //example:glibc_2_25 etiketine sahip bir constraint_value bulunduğu varsayılır. Bir platformun, bu iki kısıtlamanın dışında ek kısıtlama değerleri tanımladığı durumlarda da eşleştiğini unutmayın.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  
Tüm bu durumlarda, örneğin bir hedefin kendi konumundan farklı bir platform için oluşturulması gerekiyorsa yapılandırmanın derleme içinde değişmesi mümkündür. Bu, bir config_setting üst düzey komut satırı işaretleriyle eşleşmese bile bazı derleme hedefleriyle eşleşebileceği anlamına gelir.

Notlar

  • Birden fazla config_setting mevcut yapılandırma durumuyla eşleştiğinde ne olacağını öğrenmek için seçim bölümüne bakın.
  • Kısaltılmış biçimleri (ör. --compilation_mode - -c) destekleyen flag'ler için values tanımları tam formu kullanmalıdır. Bunlar, iki formdan birini kullanarak çağrıları otomatik olarak eşleştirir.
  • Bir işaret birden fazla değer alırsa (--copt=-Da --copt=-Db veya liste türünde Starlark işareti gibi) "a" değerinin gerçek listenin herhangi bir yerinde bulunması halinde values = { "flag": "a" } eşleşir.

    values = { "myflag": "a,b" } aynı şekilde çalışır: Bu, --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b ve --myflag=c,b,a ile eşleşir. Tam anlamlar işaretler arasında değişiklik gösterir. Örneğin, --copt aynı örnekte birden fazla değeri desteklemez: --copt=a,b, ["a,b"] değerini üretirken --copt=a --copt=b, ["a", "b"] değerini üretir (yani values = { "copt": "a,b" }, ilkiyle eşleşir ancak ikincisiyle eşleşmez). Ancak --ios_multi_cpus (Apple kuralları için) şunları yapar: -ios_multi_cpus=a,b ve ios_multi_cpus=a --ios_multi_cpus=b ikisi de ["a", "b"] oluşturur. Tam beklentileri doğrulamak için işaret tanımlarını kontrol edin ve koşullarınızı dikkatlice test edin.

  • Yerleşik derleme işaretleri tarafından modellenmeyen koşullar tanımlamanız gerekiyorsa Starlark tarafından tanımlanan işaretleri kullanın. --define öğesini de kullanabilirsiniz, ancak bu daha zayıf destek sağlar ve önerilmez. Daha fazla tartışma için buraya bakın.
  • Farklı paketlerde aynı config_setting tanımlarını tekrarlamaktan kaçının. Bunun yerine, standart pakette tanımlanan ortak bir config_setting öğesine başvurun.
  • values, define_values ve constraint_values aynı config_setting içinde herhangi bir kombinasyonda kullanılabilir ancak belirli bir config_setting için en az bir kombinasyon ayarlanmalıdır.

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.

constraint_values

Etiket listesi; yapılandırılabilir değil; varsayılan []

Hedef platformun bu config_setting ile eşleşmesi için belirtmesi gereken minimum constraint_values kümesi. (Yürütme platformu burada dikkate alınmaz.) Platformun belirlediği ek kısıtlama değerleri yoksayılır. Ayrıntılar için Yapılandırılabilir Derleme Özellikleri bölümüne bakın.

Aynı select içinde iki config_setting öğesinin eşleşmesi durumunda bu özellik, config_setting özelliklerinden birinin diğerinin uzmanlık alanı olup olmadığını belirlemek için dikkate alınmaz. Başka bir deyişle, bir config_setting bir platformla diğerinden daha güçlü bir şekilde eşleşemez.

define_values

Sözlük: Dize -> Dize; yapılandırılmamış; varsayılan değer {}

values ile aynıdır ancak yalnızca --define işareti içindir.

--define söz dizimi (--define KEY=VAL), KEY=VAL değerinin Bazel bayrağı açısından bir değer olduğu anlamına geldiği için özeldir.

Bu durumda:

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

çalışmıyor. Çünkü aynı anahtar (define) sözlükte iki kez görünüyor. Bu özellik, söz konusu sorunu çözer:

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

bazel build //foo --define a=1 --define b=2 ile doğru şekilde eşleşiyor.

--define, values içinde normal işaret söz dizimiyle görünmeye devam edebilir ve sözlük anahtarları ayrı olduğu sürece bu özellikle serbest bir şekilde karıştırılabilir.

flag_values

Sözlük: label -> Dize; yapılandırılmamış; varsayılan değer {}

values ile aynıdır ancak kullanıcı tanımlı derleme işaretleri içindir.

Yerleşik işaretler rastgele dize olarak, kullanıcı tanımlı işaretler ise etiket olarak referans alındığından bu ayrı bir özelliktir.

values

Sözlük: Dize -> Dize; yapılandırılmamış; varsayılan değer {}

Bu kuralla eşleşen yapılandırma değerleri grubu (derleme işaretleri olarak ifade edilir)

Bu kural, select ifadesinde kendisine referans veren yapılandırılmış hedefin yapılandırmasını devralır. Sözlükteki her giriş için yapılandırmasının girişin beklenen değeriyle eşleşmesi durumunda Bazel çağrısı "eşleşir". Örneğin values = {"compilation_mode": "opt"}, hedef yapılandırılmış kurallardaki bazel build --compilation_mode=opt ... ve bazel build -c opt ... çağrılarıyla eşleşir.

Kolaylık sağlamak için yapılandırma değerleri, derleme işaretleri olarak (başında "--" olmadan) belirtilir. Ancak ikisinin aynı olmadığını unutmayın. Bunun nedeni, hedeflerin aynı derleme içinde birden fazla yapılandırmayla oluşturulabilmesidir. Örneğin, bir yönetici yapılandırmasının "cpu" değeri, --cpu ile değil, --host_cpu değeriyle eşleşir. Bu nedenle, aynı config_setting öğesinin farklı örnekleri, bunları kullanan kuralın yapılandırmasına bağlı olarak aynı çağrıyla farklı şekilde eşleşebilir.

Bir işaret, komut satırında açıkça ayarlanmazsa varsayılan değeri kullanılır. Bir anahtar sözlükte birden çok kez görünüyorsa yalnızca son örneği kullanılır. Bir anahtar, komut satırında birden çok kez ayarlanabilen bir işarete referans veriyorsa (ör. bazel build --copt=foo --copt=bar --copt=baz ...) bu ayarlardan herhangi biri eşleşiyorsa eşleşme gerçekleşir.

dosya grubu

Kural kaynağını göster
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

Hedef koleksiyonuna kolay bir ad vermek için filegroup kullanın. Daha sonra bunlara diğer kurallardan referans verilebilir.

Dizinlere doğrudan referans vermek yerine filegroup kullanılması önerilir. Derleme sistemi dizin altındaki tüm dosyalar hakkında tam bilgiye sahip olmadığı için derleme sistemi sessizdir. Bu nedenle, bu dosyalar değiştiğinde yeniden oluşturma yapmayabilir. filegroup, glob ile birleştirildiğinde tüm dosyaların derleme sistemi tarafından açıkça bilinmesini sağlayabilir.

Örnekler

İki kaynak dosyadan oluşan bir filegroup oluşturmak için

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

Veya bir test verisi dizini oluşturmak için bir glob kullanın:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

Bu tanımlardan yararlanmak için filegroup öğesine herhangi bir kuraldan etiket ekleyin:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.

srcs

Etiket listesi; varsayılan []

Dosya grubunun üyesi olan hedeflerin listesi.

Bir glob ifadesinin sonucu, srcs özelliğinin değeri için yaygın olarak kullanılır.

data

Etiket listesi; varsayılan []

Çalışma zamanında bu kuralın ihtiyaç duyduğu dosyaların listesi.

data özelliğinde belirtilen hedefler, bu filegroup kuralının runfiles öğesine eklenir. filegroup öğesine başka bir kuralın data özelliğinde referans verildiğinde, runfiles özelliği bağlı kuralın runfiles öğesine eklenir. Veri dosyalarına nasıl bağımlı olabileceğiniz ve bu dosyaların nasıl kullanılacağı hakkında daha fazla bilgi için veri bağımlılıkları bölümüne ve data ile ilgili genel belgeleri inceleyin.

output_group

Dize; varsayılan değer ""

Kaynaklardan yapıların toplanacağı çıkış grubu. Bu özellik belirtilirse bağımlılıkların belirtilen çıkış grubundaki yapılar varsayılan çıkış grubu yerine dışa aktarılır.

"Çıkış grubu", bir kuralın uygulamasında belirtilen ve bir hedefin çıkış yapılarının kategorisidir.

Genquery

Kural kaynağını göster
genquery(name, deps, data, compatible_with, compressed_output, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery(), Blaze sorgu dilinde belirtilen bir sorguyu çalıştırır ve sonucu bir dosyaya döküm.

Derlemenin tutarlılığını sağlamak için sorgunun yalnızca scope özelliğinde belirtilen hedeflerin geçişli kapanışını ziyaret etmesine izin verilir. strict belirtilmemişse veya doğru değerine ayarlanırsa bu kuralı ihlal eden sorgular yürütme sırasında başarısız olur (strict yanlış değerine ayarlanırsa kapsam dışı hedefler bir uyarıyla atlanır). Bunun olmamasını sağlamanın en kolay yolu, sorgu ifadesinde belirtilenle aynı etiketleri kapsam içinde belirtmektir.

Burada ve komut satırında izin verilen sorgular arasındaki tek fark, joker karakter hedef özellikleri (ör. //pkg:* veya //pkg:all) içeren sorgulara burada izin verilmemesidir. Bunun iki nedeni vardır. Birincisi, genquery ürününün, çıkışını etkilemesi için sorgunun geçişli olarak kapatılması dışındaki hedeflerin önlenmesi için bir kapsam belirtmesi gerekir. İkinci olarak, BUILD dosyaları joker karakter bağımlılıklarını desteklemediğinden (ör. deps=["//a/..."]'ye izin verilmez).

--output=graph|minrank|maxrank hariç olmak üzere veya üst düzey işlev olarak somepath kullanıldığında, sorgu çıkışı deterministik çıktıyı uygulamak için sözlüksel olarak sıralanır.

Çıkış dosyasının adı kuralın adıdır.

Örnekler

Bu örnekte, belirtilen hedefin geçişli kapatma işlemindeki etiketlerin listesi bir dosyaya yazılmaktadır.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.

compressed_output

Boole; varsayılan değer False

True ise sorgu çıkışı GZIP dosyası biçiminde yazılır. Bu ayar, sorgu çıkışının büyük olması beklenirken Bazel'in bellek kullanımındaki ani artışları önlemek için kullanılabilir. Bazel, bu ayarın değerinden bağımsız olarak 220 bayttan büyük sorgu çıkışlarını zaten dahili olarak sıkıştırır. Bu nedenle, bu ayarın True olarak ayarlanması, saklanan yığını azaltmayabilir. Ancak, çıkış dosyasını yazarken Bazel'in sıkıştırmayı atlamasına olanak tanır. Bu işlem, yoğun bellek kullanımına neden olabilir.
expression

Dize; zorunlu

Yürütülecek sorgu. Komut satırı ve BUILD dosyalarındaki diğer yerlerin aksine buradaki etiketler, çalışma alanının kök dizinine göre çözümlenir. Örneğin, a/BUILD dosyasındaki bu özellikte bulunan :b etiketi, //:b hedefini ifade eder.
opts

Dize listesi; varsayılan değer: []

Sorgu motoruna iletilen seçenekler. Bunlar, bazel query hizmetine iletilebilen komut satırı seçeneklerine karşılık gelir. Burada bazı sorgu seçeneklerine izin verilmez: --keep_going, --query_file, --universe_scope, --order_results ve --order_output. Burada belirtilmeyen seçenekler, bazel query komut satırındaki gibi varsayılan değerlerine sahip olur.
scope

Etiket listesi; zorunlu

Sorgunun kapsamı. Sorgunun, bu hedeflerin geçişli olarak kapatılması dışındaki hedeflere dokunmasına izin verilmez.
strict

Boole; varsayılan değer True

Doğru değerine ayarlanırsa sorguları kapsamlarının geçişli kapanmasından kaçan hedefler derlenemez. False (yanlış) değerine ayarlanırsa Bazel bir uyarı yazdırır ve onu kapsam dışına yönlendiren sorgu yolunu atlayarak sorgunun geri kalanını tamamlar.

Genrule

Kural kaynağını göster
genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule, kullanıcı tanımlı Bash komutunu kullanarak bir veya daha fazla dosya oluşturur.

Genrule, görev için belirli bir kural yoksa kullanabileceğiniz genel derleme kurallarıdır. Örneğin, Bash tek satırlık bir hazırlayabilirsiniz. Yine de C++ dosyalarını derlemeniz gerekiyorsa mevcut cc_* kurallarına bağlı kalın. Tüm ağır işlemler sizin yerinize zaten yapılmıştır.

Genrule öğesinin, komut bağımsız değişkenini yorumlamak için kabuk gerektirdiğini unutmayın. PATH üzerinde bulunan rastgele programlara başvurmak da kolaydır. Ancak bu, komutu hermetik hale getirir ve yeniden üretemeyebilir. Yalnızca tek bir araç çalıştırmanız gerekiyorsa bunun yerine run_binary'yi kullanabilirsiniz.

Testleri çalıştırmak için genrule kullanmayın. Testler ve test sonuçları için önbelleğe alma politikaları ve ortam değişkenleri de dahil olmak üzere özel dağıtımlar vardır. Testlerin genellikle derleme tamamlandıktan sonra ve hedef mimari üzerinde çalıştırılması gerekir. Öte yandan, genel kurallar derleme sırasında ve yönetici mimarisi üzerinde yürütülür (ikisi farklı olabilir). Genel amaçlı bir test kuralına ihtiyacınız varsa sh_test kullanın.

Çapraz derlemede dikkat edilmesi gereken noktalar

Çapraz derleme hakkında daha fazla bilgi için kullanıcı kılavuzunu inceleyin.

Genrule'lar derleme sırasında çalışır ancak çıkışları genellikle derlemeden sonra dağıtım veya test için kullanılır. Mikrodenetleyici için C kodu derleme örneğini düşünün: Derleyici, C kaynak dosyalarını kabul eder ve bir mikrodenetleyicide çalışan kod oluşturur. Oluşturulan kodun, kendisini oluşturmak için kullanılan CPU'da çalıştırılamayacağı açık şekilde, ancak C derleyicisinin (kaynaktan derlenmişse) kendisinin çalışması gerekir.

Derleme sistemi, derlemenin çalıştığı makineleri tanımlamak için yönetici yapılandırmasını ve derleme çıkışının çalışması gereken makineleri açıklamak için hedef yapılandırmayı kullanır. Bunların her birini yapılandırma seçenekleri sunar ve çakışmaları önlemek için karşılık gelen dosyaları ayrı dizinlere ayırır.

Genrule'lar için derleme sistemi, bağımlılıkların uygun şekilde oluşturulmasını sağlar: target yapılandırması için srcs oluşturulur, tools exec yapılandırması için oluşturulur ve çıkışın hedef yapılandırması için olduğu kabul edilir. Ayrıca, Genrule komutların ilgili araçlara iletebileceği "Make" değişkenleri de sağlar.

Genel kuralların herhangi bir deps özelliği tanımlamaması kasıtlıdır. Diğer yerleşik kurallar, bağımlı kuralların nasıl ele alınacağını otomatik olarak belirlemek için kurallar arasında iletilen dile bağlı meta bilgileri kullanır ancak genel kurallar için bu düzeyde otomasyon mümkün değildir. Genrule'lar yalnızca dosya ve çalıştırma dosyaları düzeyinde çalışır.

Özel Durumlar

Exec-exec derlemesi: Bazı durumlarda derleme sisteminin, çıkışın derleme sırasında da yürütülebilmesi için genrule çalıştırması gerekir. Örneğin, bir genrule, daha sonra başka bir Genrule tarafından kullanılacak bir özel derleyici derlerse ilkinin, yürütme yapılandırması için çıktısını oluşturması gerekir. Çünkü derleyici bu aşamada diğer genel kuralda da çalışır. Bu durumda, derleme sistemi otomatik olarak doğru şeyi yapar: hedef yapılandırma yerine yönetici yapılandırması için ilk genel kuralın srcs ve outs öğesini oluşturur. Daha fazla bilgi için kullanım kılavuzuna bakın.

JDK ve C++ Araçları: JDK veya C++ derleyici paketindeki bir aracı kullanmak için derleme sistemi, kullanılacak bir dizi değişken sağlar. Ayrıntılar için "Yap" değişkeni bölümüne bakın.

Genel ortam

Genrule komutu, bir komut veya ardışık düzen başarısız olduğunda başarısız olacak şekilde yapılandırılan Bash kabuğu tarafından set -e -o pipefail kullanılarak yürütülür.

Derleme aracı; Bash komutunu yalnızca PATH, PWD, TMPDIR ve birkaç diğer temel değişkenleri tanımlayan temiz bir işlem ortamında yürütür. Derlemelerin tekrarlanabilir olmasını sağlamak için kullanıcının kabuk ortamında tanımlanan çoğu değişken, Genrule (Genrule) komutuna iletilmez. Bununla birlikte, Bazel (Blaze değil) kullanıcının PATH ortam değişkeninin değerinden geçer. PATH değerinde yapılan herhangi bir değişiklik, Bazel'in bir sonraki derlemede komutu yeniden yürütmesine neden olur.

Genrule komutu, şu anda zorunlu olmasa da komutun alt öğeleri olan işlemleri bağlamak dışında ağa erişmemelidir.

Derleme sistemi mevcut çıkış dosyalarını otomatik olarak siler, ancak bir genrule çalıştırmadan önce gerekli tüm üst dizinleri oluşturur. Ayrıca, hata durumunda çıkış dosyalarını da kaldırır.

Genel Tavsiye

  • Bir genel kural tarafından çalıştırılan araçların deterministik ve hermetik olduğundan emin olun. Çıkışlarına zaman damgaları yazmamalı, kümeler ve haritalar için sabit sıralama kullanmalı, mutlak yollar kullanmamalı, çıkışa yalnızca göreli dosya yolları yazmalıdır. Bu kurala uyulmaması, beklenmeyen derleme davranışlarına (Bazel'in beklediğiniz bir genel kuralı yeniden oluşturmamasına) ve önbellek performansının düşmesine neden olur.
  • $(location) öğesini çıkışlar, araçlar ve kaynaklar için yoğun bir şekilde kullanın. Çıkış dosyalarının farklı yapılandırmalara göre ayrılması nedeniyle, genruller sabit kodlu ve/veya mutlak yollara dayanamaz.
  • Aynı veya çok benzer kişilerin birden fazla yerde kullanılması ihtimaline karşı ortak bir Starlark makrosu yazın. Genel kural karmaşıksa bir komut dosyasında veya Starlark kuralı olarak uygulamayı düşünebilirsiniz. Bu sayede okunabilirliği ve test edilebilirliği iyileştirebilirsiniz.
  • Çıkış kodunun, kuralın başarılı veya başarısız olduğunu doğru şekilde gösterdiğinden emin olun.
  • stdout veya stderr'e bilgilendirme amaçlı iletiler yazmayın. Hata ayıklama için faydalı olsa da bu, kolayca gürültüye dönüşebilir. Başarılı bir oluşturucu sessiz olmalıdır. Diğer yandan, başarısız bir genel kural iyi hata mesajları vermelidir.
  • $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
  • Sembol bağlantılar ve dizinler oluşturmaktan kaçının. Bazel, Genrule'lar tarafından oluşturulan dizin/simgesel bağlantı yapısını kopyalamaz ve dizinler için bağımlılık kontrolü düzgün değildir.
  • Diğer kurallarda genel kurala referans verirken genel kuralın etiketini veya ayrı ayrı çıkış dosyalarının etiketlerini kullanabilirsiniz. Bazen bir yaklaşım daha okunabilir olur, bazen diğeri: tüketici kuralının srcs öğesinde çıkışlara isme göre referans vermek, istemeden genrule'ın diğer çıktılarını toplamaktan kaçınır ancak genel kural çok sayıda çıktı üretiyorsa yorucu olabilir.

Örnekler

Bu örnek, foo.h oluşturur. Komut giriş almadığı için kaynak yok. Komut tarafından çalıştırılan "ikili", genrule ile aynı pakette bulunan bir perl komut dosyasıdır.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

Aşağıdaki örnekte filegroup özelliğinin nasıl kullanılacağı ve başka bir genrule öğesinin çıkışları gösterilmektedir. Açık $(location) yönergeleri yerine $(SRCS) kullanıldığında da işe yarayacağını unutmayın. Bu örnekte, örneği göstermek amacıyla ikinci kural kullanılmaktadır.

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.


Bu kurala, diğer BUILD kurallarının srcs veya deps bölümünde yer alan adla başvurabilirsiniz. Kural, kaynak dosyalar oluşturuyorsa srcs özelliğini kullanmanız gerekir.
srcs

Etiket listesi; varsayılan []

Bu kuralla ilgili girişlerin (ör. işlenecek kaynak dosyaları) listesi.

Bu özellik, cmd tarafından yürütülen araçların listelenmesi için uygun değildir. Bunun yerine tools özelliğini kullanın.

Derleme sistemi, bu ön koşulların genrule komutunu çalıştırmadan önce oluşturulmasını sağlar. Bunlar, orijinal derleme isteğiyle aynı yapılandırma kullanılarak oluşturulur. Bu ön koşullara ilişkin dosyaların adları, $(SRCS) içinde boşlukla ayrılmış bir liste olarak komut tarafından kullanılabilir. Alternatif olarak, bağımsız bir srcs hedefinin //x:y yolu, $(location //x:y) kullanılarak veya srcs içindeki tek giriş olması koşuluyla $< kullanılarak elde edilebilir.

outs

Dosya adları listesi; yapılamayan; gerekli

Bu kural tarafından oluşturulan dosyaların listesi.

Çıkış dosyaları, paket sınırlarını geçmemelidir. Çıkış dosya adları pakete göre yorumlanır.

executable işareti ayarlanırsa outs tam olarak bir etiket içermelidir.

Genrule komutunun her çıkış dosyasını önceden belirlenmiş bir konumda oluşturması beklenir. Konum, cmd üzerinde genel kurala özel "Marka" değişkenleri ($@, $(OUTS), $(@D) veya $(RULEDIR)) veya $(location) değişikliklerini kullanarak mevcuttur.

cmd

Dize; varsayılan değer ""

Çalıştırılacak komut. $(location) ve "Yap" değişkeni değişikliğine tabidir.
  1. Tüm $(location label) ve $(locations label) tekrarları (ve execpath, execpaths, rootpath ve rootpaths ilgili değişkenlerini kullanan benzer yapılar) değiştirilerek ilk $(location) değişikliği uygulanır.
  2. Ardından, "Yap" değişkenleri genişletilir. Önceden tanımlanmış $(JAVA), $(JAVAC) ve $(JAVABASE) değişkenlerinin exec yapılandırması altında genişlediğini unutmayın. Böylece, derleme adımının parçası olarak çalışan Java çağrıları, paylaşılan kitaplıkları ve diğer bağımlılıkları doğru şekilde yükleyebilir.
  3. Son olarak, elde edilen komut Bash kabuğu kullanılarak yürütülür. Çıkış kodu sıfır değilse komutun başarısız olduğu kabul edilir.
Bu, hiçbiri geçerli değilse cmd_bash, cmd_ps ve cmd_bat yedeğidir.

Komut satırı uzunluğu, platform sınırını (Linux/macOS'te 64K, Windows'da 8K) aşarsa genrule, komutu bir komut dosyasına yazar ve geçici olarak bu komut dosyasını yürütür. Bu, tüm cmd özellikleri (cmd, cmd_bash, cmd_ps, cmd_bat) için geçerlidir.

cmd_bash

Dize; varsayılan değer ""

Çalıştırılacak Bash komutu.

Bu özelliğin önceliği, cmd değerinden daha yüksek. Komut, cmd özelliğiyle tam olarak aynı şekilde genişletilir ve çalışır.

cmd_bat

Dize; varsayılan değer ""

Windows'da çalıştırılacak Batch komutu.

Bu özelliğin önceliği, cmd ve cmd_bash özelliklerine göre daha yüksek. Komut, cmd özelliğine benzer şekilde çalışır ancak aşağıdaki farklılıklara sahiptir:

  • Bu özellik yalnızca Windows'da geçerlidir.
  • Bu komut, aşağıdaki varsayılan bağımsız değişkenlerle birlikte cmd.exe /c ile çalışır:
    • /S - İlk ve son alıntıları ayıklayın ve diğer her şeyi olduğu gibi yürütün.
    • /E:ON - Genişletilmiş komut kümesini etkinleştir.
    • /V:ON - gecikmeli değişken genişletmeyi etkinleştirme
    • /D - AutoRun kayıt defteri girişlerini yoksayın.
  • $(location) ve "Make" değişkeninin değiştirilmesinden sonra, yollar, Windows stil yollarına (ters eğik çizgiyle) genişletilir.
cmd_ps

Dize; varsayılan değer ""

Windows'da çalıştırılacak Powershell komutu

Bu özellik; cmd, cmd_bash ve cmd_bat özelliklerine göre daha yüksek önceliğe sahip. Komut, cmd özelliğine benzer şekilde çalışır ancak aşağıdaki farklılıklara sahiptir:

  • Bu özellik yalnızca Windows'da geçerlidir.
  • Komut, powershell.exe /c ile çalışır.

Powershell'in kullanımını daha kolay ve hataya daha az açık hale getirmek için genrule öğesinde Powershell komutunu çalıştırmadan önce ortamı ayarlamak amacıyla aşağıdaki komutları çalıştırıyoruz.

  • Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - İmzalanmamış komut dosyalarının çalıştırılmasına izin verir.
  • $errorActionPreference='Stop' - ; ile ayrılmış birden fazla komut olması durumunda, Powershell CmdLet'i başarısız olursa işlem hemen çıkar, ancak bu harici komutta ÇALIŞMAZ.
  • $PSDefaultParameterValues['*:Encoding'] = 'utf8' - utf-16 olan varsayılan kodlamayı utf-8 olarak değiştirin.
executable

Boole; yapılandırılmamış; varsayılan değer False

Çıkışı yürütülebilir olarak bildir.

Bu işaretin Doğru değerine ayarlanması, çıktının yürütülebilir bir dosya olduğu ve run komutu kullanılarak çalıştırılabileceği anlamına gelir. Bu durumda Genrule tam olarak bir çıkış üretmelidir. Bu özellik ayarlanırsa run, içeriğinden bağımsız olarak dosyayı yürütmeyi dener.

Oluşturulan yürütülebilir dosya için veri bağımlılıklarının tanımlanması desteklenmiyor.

local

Boole; varsayılan değer False

Doğru değerine ayarlanırsa bu seçenek, bu genrule öğesini "yerel" stratejiyle çalışmaya zorlar. Bu da uzaktan yürütme, korumalı alan oluşturma veya kalıcı çalışan olmayacak anlamına gelir.

Bu, etiket olarak "yerel" değerinin sağlanmasına eşdeğerdir (tags=["local"]).

message

Dize; varsayılan değer ""

İlerleme durumu mesajı.

Bu derleme adımı yürütüldüğünde yazdırılacak bir ilerleme mesajı. Varsayılan olarak "Çıkış oluşturma" mesajı (ya da eşit derecede uygunsuz bir mesaj) olur ancak daha spesifik bir mesaj sağlayabilirsiniz. cmd komutunuzda echo veya diğer yazdırma ifadeleri yerine bu özelliği kullanın. Çünkü bu, derleme aracının ilerleme mesajlarının yazdırılıp yazdırılmayacağını kontrol etmesine olanak tanır.

output_licenses

Lisans türü; varsayılan değer: ["none"]

Bkz. common attributes
output_to_bindir

Boole; yapılandırılmamış; varsayılan değer False

Doğru değerine ayarlanırsa bu seçenek, çıkış dosyalarının genfiles dizini yerine bin dizinine yazılmasına neden olur.

tools

Etiket listesi; varsayılan []

Bu kural için araç bağımlılıklarının listesi. Daha fazla bilgi için bağımlılıkların tanımına bakın.

Derleme sistemi, bu ön koşulların genrule komutunu çalıştırmadan önce oluşturulmasını sağlar. Bu ön koşullar, derlemenin bir parçası olarak yürütüldüğü için exec yapılandırması kullanılarak oluşturulur. Tek bir tools hedefinin //x:y yolu $(location //x:y) kullanılarak elde edilebilir.

cmd tarafından yürütülecek tüm *_binary veya araçlar doğru yapılandırmada oluşturulduğundan emin olmak için srcs içinde değil bu listede görünmelidir.

starlark_doc_extract

Kural kaynağını göster
starlark_doc_extract(name, deps, src, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, licenses, render_main_repo_name, restricted_to, symbol_names, tags, target_compatible_with, testonly, visibility)

starlark_doc_extract(), belirli bir .bzl veya .scl dosyasında tanımlanan veya yeniden dışa aktarılan kurallar, işlevler (makrolar dahil), özellikler ve sağlayıcılarla ilgili dokümanları ayıklar. Bu kuralın sonucu, Bazel kaynak ağacındaki stardoc_output.proto bölümünde tanımlandığı gibi bir ModuleInfo ikili programıdır.

Dolaylı çıkış hedefleri

  • name.binaryproto (varsayılan çıkış): ModuleInfo ikili programı.
  • name.textproto (yalnızca açıkça talep edildiğinde oluşturulur): name.binaryproto metin protokolü sürümü.

Uyarı: Bu kuralın çıkış biçiminin kararlı olacağı garanti edilmez. Esas olarak Stardoc tarafından dahili kullanım için tasarlanmıştır.

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.

deps

Etiket listesi; varsayılan []

src tarafından load() gönderilen Starlark dosyalarını sarmalayan hedeflerin listesi. Bu hedeflerin, normal kullanım altında bzl_library hedefleri olması gerekir ancak starlark_doc_extract kuralı bunu zorunlu kılmaz ve DefaultInfo içinde Starlark dosyaları sağlayan herhangi bir hedefi kabul eder.

Sarmalanmış Starlark dosyalarının kaynak ağaçta yer alan dosyalar olması gerektiğini unutmayın. Bazel, oluşturulan load() dosyaları kullanamaz.

src

Label; zorunlu

Belgelerin çıkarılacağı Starlark dosyası.

Bunun kaynak ağaçta bir dosya olması gerektiğini unutmayın. Bazel, oluşturulan dosyaları load() yapamaz.

render_main_repo_name

Boole; varsayılan değer False

True (doğru) değerine ayarlanırsa bir depo bileşeniyle yayınlanan belgelerde ana depodaki etiketleri oluşturun (diğer bir deyişle //foo:bar.bzl, @main_repo_name//foo:bar.bzl olarak yayınlanır).

Ana depo için kullanılacak ad, ana deponun MODULE.bazel dosyasındaki module(name = ...) öğesinden (Bzlmod etkinse) veya ana deponun WORKSPACE dosyasındaki workspace(name = ...) dosyasından alınır.

Bu özellik, yalnızca aynı depoda kullanılması amaçlanan Starlark dosyaları için doküman oluştururken False olarak, diğer depolarda kullanılması amaçlanan Starlark dosyalarıyla ilgili ise belge oluştururken True olarak ayarlanmalıdır.

symbol_names

Dize listesi; varsayılan değer: []

Dokümanların ayıklanacağı dışa aktarılan işlevlerin, kuralların, sağlayıcıların veya özelliklerinin (ya da iç içe yerleştirildikleri struct'ların) nitelikli adlarının isteğe bağlı bir listesi. Burada nitelikli ad, varlığın ad alanı için iç içe yerleştirildiği tüm struct'lar dahil olmak üzere, bir varlığın modül kullanıcılarına sunulurken kullanılan adı ifade eder.

starlark_doc_extract, yalnızca şu durumlarda varlığa ait dokümanları yayınlar:

  1. varlığın nitelikli adının her bileşeni herkese açıktır (başka bir deyişle, nitelikli adın her bileşeninin ilk karakteri "_" değil, alfabetiktir); ve
    1. symbol_names listesi boş (varsayılan durumda) veya
    2. Varlığın nitelikli adı veya varlığın iç içe yerleştirildiği bir struct'ın nitelikli adı symbol_names listesindedir.

test_suite

Kural kaynağını göster
test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite, kullanıcılar için "faydalı" olarak kabul edilen bir dizi testi tanımlar. Bu sayede projeler, "kontrol etmeden önce çalıştırmanız gereken testler", "projemizin stres testleri" veya "tüm küçük testler" gibi test setleri tanımlayabilir. blaze test komutu şu organizasyona uyar: blaze test //some/test:suite gibi bir çağrı için Blaze önce //some/test:suite hedefi tarafından geçişli olarak dahil edilen tüm test hedeflerini numaralandırır (buna "test_suite genişletmesi" denir), ardından Blaze bu hedefleri oluşturup test eder.

Örnekler

Mevcut paketteki tüm küçük testleri çalıştıracak bir test paketi.

test_suite(
    name = "small_tests",
    tags = ["small"],
)

Belirli bir test grubunu çalıştıran bir test paketi:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

Mevcut pakette stabil olmayan tüm testleri çalıştırmak için kullanılan bir test paketi.

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

Bağımsız değişkenler

Özellikler
name

Ad; gerekli

Bu hedef için benzersiz bir ad.

tags

Dize listesi; yapılandırılabilir olmayan; varsayılan []

"small" veya "database" ya da "-flaky" gibi metin etiketlerinin listesi. Etiketler herhangi bir geçerli dize olabilir.

"-" karakteriyle başlayan etiketler negatif etiket olarak kabul edilir. Önceki "-" karakteri, etiketin bir parçası olarak kabul edilmez. Bu nedenle, "-small" paket etiketi testin "small" boyutuyla eşleşir. Diğer tüm etiketler pozitif etiketler olarak kabul edilir.

İsteğe bağlı olarak, pozitif etiketleri daha açık hale getirmek için etiketler, etiket metninin bir parçası olarak değerlendirilmeyecek "+" karakteriyle de başlayabilir. Yalnızca pozitif ve negatif ayrımı daha kolay okunur hale getirir.

Yalnızca pozitif etiketlerin tümüyle eşleşen ve negatif etiketlerin hiçbiri ile eşleşen test kuralları test paketine dahil edilir. Bunun, filtrelenen testlerdeki bağımlılıkları kontrol etme hatasının atlanacağı anlamına gelmediğini unutmayın.Atlanan testlere yönelik bağımlılıkların yine de yasal olması (ör. görünürlük kısıtlamaları tarafından engellenmemesi) gerekir.

manual etiketi anahtar kelimesi, joker karakterli hedef kalıpları içeren çağrılarda blaze test komutu tarafından gerçekleştirilen "test_suite genişletmesi" tarafından yukarıdakinden farklı şekilde işlenir. Burada "manuel" olarak etiketlenen test_suite hedef filtrelenir (dolayısıyla genişletilmez). Bu davranış, blaze build ve blaze test öğelerinin genel olarak joker karakter hedef kalıplarını işleme şekliyle tutarlıdır. Süitler, manual etiketinden bağımsız olarak her zaman tests sorgu işleviyle genişletildiğinden, bunun blaze query 'tests(E)' davranışından açıkça farklı olduğunu unutmayın.

Bir testin size değerinin, filtreleme amacıyla bir etiket olarak kabul edildiğini unutmayın.

Birlikte dışlayıcı etiketlere sahip testler içeren (ör.tüm küçük ve orta testler) testler içeren bir test_suite kuralına ihtiyacınız varsa (ör. tüm küçük ve orta testler) bir tane tüm küçük testler için bir tane, tüm aracı testleri için bir tane ve önceki ikisini içeren bir tane olmak üzere üç test_suite kuralı oluşturmanız gerekir.

tests

Etiket listesi; yapılandırılabilir değil; varsayılan []

Herhangi bir dildeki test paketlerinin ve test hedeflerinin listesi.

Dilinden bağımsız olarak burada tüm *_test kabul edilir. Ancak test yapsalar bile *_binary hedefleri kabul edilmez. Belirtilen tags değerine göre filtreleme, yalnızca doğrudan bu özellikte listelenen testler için yapılır. Bu özellik test_suite içeriyorsa bunların içindeki testler bu test_suite tarafından filtrelenmez (bunlar zaten filtrelenmiş olarak kabul edilir).

tests özelliği belirtilmemiş veya boşsa kural varsayılan olarak mevcut BUILD dosyasına manual olarak etiketlenmemiş tüm test kurallarını dahil eder. Bu kurallar hâlâ tag filtrelemesine tabidir.