Genel Kurallar

Kurallar

• takma ad
• config_setting
• dosya grubu
• Genquery
• genrule
• test_suite

takma ad

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias kuralı, kuralın bahsedilebileceği başka bir ad oluşturur.

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

Takma ad kuralının kendi görünürlük beyanı vardır. Diğer tüm açılardan, bazı küçük istisnalar dışında referans aldığı kural gibi davranır (ör. takma adda testonly çıkarılır; bunun yerine referans verilen kuralın salt test durumu kullanılır):

• Komut satırında takma adlarından bahsedilmişse testler çalıştırılmaz. Başvurulan testi çalıştıran bir takma ad tanımlamak için tests özelliğinde tek hedefi olan 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	Name; required Bu hedef için benzersiz bir ad.
actual	Label; required Bu takma adın ifade ettiği hedef. Kural olması gerekmez. Giriş dosyası da olabilir.

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

Yapılandırılabilir özellikleri tetiklemek amacıyla, beklenen bir yapılandırma durumuyla (derleme bayrakları veya platform kısıtlamaları olarak ifade edilir) eşleşir. Bu kuralın nasıl kullanılacağını öğrenmek için seçme bölümüne ve genel özelliğe genel bir bakış için Yapılandırılabilir özelliklere bakın.

Örnekler

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

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

Aşağıdaki, ARM'yi hedefleyen ve FOO=bar özel tanımını uygulayan tüm derlemelerle 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ğıdakiler, kullanıcı tanımlı işareti --//custom_flags:foo=1 ayarlayan (komut satırında açıkça veya dolaylı olarak .bazelrc dosyalarından) tüm derlemelerle eşleşir:

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

Aşağıdaki, //example:glibc_2_25 etiketine sahip bir constraint_value varlığı varsa x86_64 mimarisine ve glibc sürümü 2.25'e sahip bir platformu hedefleyen tüm derlemelerle eşleşir. Bir platformun, bu ikisinin ötesinde ek kısıtlama değerleri tanımladığı takdirde yine 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, yapılandırmanın derleme içinde değişebilir. Örneğin, bir hedefin atamasından farklı bir platform için derlenmesi gerekiyorsa. 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

• Geçerli yapılandırma durumuyla birden fazla config_setting eşleştiğinde ne olacağını öğrenmek için seçme bölümüne bakın.
• Kestirme biçimleri destekleyen işaretler için (ör. --compilation_mode ve -c) values tanımları için tam biçim kullanılmalıdır. Bunlar, formlardan herhangi birini kullanarak çağrıları otomatik olarak eşleştirir.
• Bir işaret birden fazla değer alıyorsa (--copt=-Da --copt=-Db veya liste türünde bir Starlark flag gibi) "a" gerçek listede herhangi bir yerde mevcutsa 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. Kesin anlamlar, işaretler arasında farklılık gösterir. Örneğin --copt, aynı örnekte birden çok değeri desteklemez: --copt=a,b ["a,b"] değerini, --copt=a --copt=b ise ["a", "b"] sonucunu verir (dolayısıyla 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 hem ["a", "b"] üretir. Beklentileri tam olarak doğrulamak için işaret tanımlarını kontrol edin ve koşullarınızı dikkatli bir şekilde 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 kullanabilirsiniz ancak bu daha zayıf bir destek sunar ve önerilmez. Daha fazla bilgi için buraya göz atabilirsiniz.
• Farklı paketlerde aynı config_setting tanımlarını tekrarlamayın. Bunun yerine, standart pakette tanımlanan ortak bir config_setting öğesine referans verin.
• values, define_values ve constraint_values, aynı config_setting içindeki herhangi bir kombinasyonda kullanılabilir ancak belirli bir config_setting için en az bir tanesi ayarlanmalıdır.

Bağımsız değişkenler

Özellikler
name	Name; required Bu hedef için benzersiz bir ad.
constraint_values	List of labels; optional; nonconfigurable Bu config_setting ile eşleşme için hedef platformun belirtmesi gereken minimum constraint_values grubu. (Yürütme platformu burada dikkate alınmaz.) Platformun belirttiği ek kısıtlama değerleri göz ardı edilir. Ayrıntılar için Yapılandırılabilir Derleme Özellikleri bölümüne bakın. İki config_setting öğesinin aynı select içinde eşleştiği durumlarda bu özellik, config_setting özelliklerinden birinin diğerinin uzmanlığı olup olmadığını belirlemek amacıyla dikkate alınmaz. Diğer bir deyişle, bir config_setting bir platformla diğerinden daha güçlü bir şekilde eşleşemez.
define_values	Dictionary: String -> String; optional; nonconfigurable values ile aynıdır, ancak özellikle --define işareti için. --define söz dizimi (--define KEY=VAL), KEY=VAL değerinin Bazel işareti açısından bir değer olduğu anlamına geldiğinden özeldir. Bu durumda: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) sözlükte iki kez göründüğü için aynı anahtar (define) çalışmaz. Bu özellik, 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 bir şekilde eşleşiyor. --define, values içinde normal işaret söz dizimiyle görünmeye devam edebilir ve sözlük anahtarları farklı kaldığı sürece bu özellikle serbest bir şekilde karıştırılabilir.
flag_values	Dictionary: label -> String; optional; nonconfigurable values ile aynıdır ancak kullanıcı tanımlı derleme işaretleri için geçerlidir. Bu ayrı bir özelliktir çünkü kullanıcı tanımlı işaretlere etiket olarak, yerleşik işaretlere ise rastgele dizelere başvurulur.
values	Dictionary: String -> String; optional; nonconfigurable Bu kuralla eşleşen yapılandırma değerleri grubu (derleme işareti olarak ifade edilir) Bu kural, select ifadesinde kendisine referans veren yapılandırılmış hedefin yapılandırmasını devralır. Sözlükte her bir girişin yapılandırması girişin beklenen değeriyle eşleşiyorsa bir Bazel çağrısıyla "eşleşiyor" olarak kabul edilir. Ö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ğlaması açısından, yapılandırma değerleri derleme işareti olarak (önceki "--" olmadan) belirtilir. Ancak ikisinin aynı olmadığını unutmayın. Bunun nedeni, hedeflerin aynı derlemede birden fazla yapılandırmada oluşturulabilmesidir. Örneğin, bir ana makine yapılandırmasının "cpu" değeri, --cpu ile değil, --host_cpu değeriyle eşleşir. Dolayısıyla, 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 ayarlanmamışsa varsayılan değeri kullanılır. Bir anahtar, sözlükte birden çok kez görünüyorsa yalnızca son örnek 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şirse eşleşme gerçekleşir.

dosya grubu

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

Hedef koleksiyonuna uygun 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. İkincisi, derleme sistemi dizin altındaki tüm dosyalar hakkında tam bilgiye sahip olmadığından bir sorun teşkil etmez. Bu nedenle, söz konusu dosyalar değiştiğinde uygulama yeniden oluşturulmayabilir. glob ile birleştirildiğinde filegroup, tüm dosyaların derleme sistemi tarafından açık bir şekilde bilinmesini sağlayabilir.

Örnekler

İki kaynak dosyadan oluşan bir filegroup oluşturmak için şunu yapın:

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

Alternatif olarak, bir test verileri dizininde gezinmek 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 etiketi 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	Name; required Bu hedef için benzersiz bir ad.
srcs	List of labels; optional Dosya grubunun üyesi olan hedeflerin listesi. srcs özelliğinin değeri için glob ifadesinin sonucu yaygın olarak kullanılır.
data	List of labels; optional Bu kuralın çalışma zamanında ihtiyaç duyduğu dosyaların listesi. data özelliğinde adlandırılmış hedefler, bu filegroup kuralının runfiles bölümüne eklenir. filegroup öğesine başka bir kuralın data özelliğinde referans verildiğinde, öğenin runfiles değeri, bağlı kuralının runfiles öğesine eklenir. Veri dosyalarına nasıl güveneceğiniz ve bu dosyaları nasıl kullanacağınız hakkında daha fazla bilgi için veri bağımlılıkları bölümüne ve data ile ilgili genel dokümanlara bakın.
output_group	String; optional Kaynaklardaki yapıların toplanacağı çıkış grubu. Bu özellik belirtilirse varsayılan çıkış grubu yerine bağımlılıkların belirtilen çıkış grubundaki yapılar dışa aktarılır. "Çıkış grubu", kuralın uygulamasında belirtilen, bir hedefin çıkış yapıları kategorisidir.

Genquery

genquery(name, deps, data, compatible_with, 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 aktarır.

Derlemenin tutarlı olması için sorgunun yalnızca scope özelliğinde belirtilen hedeflerin geçişli kapanışını ziyaret etmesine izin verilir. strict belirtilmezse veya doğru değerine ayarlanırsa bu kuralı ihlal eden sorgular, yürütülürken 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, kapsam içinde sorgu ifadesindeki ile aynı etiketleri belirtmektir.

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

Oluşturulan sorgunun çıkışı, belirleyici çıkışı zorunlu kılmak için --order_output=full kullanılarak sıralanır.

Çıktı dosyasının adı, kuralın adıdır.

Örnekler

Bu örnekte, belirtilen hedefin geçişli kapanışındaki etiketlerin listesini bir dosyaya yazar.

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

Bağımsız değişkenler

Özellikler
name	Name; required Bu hedef için benzersiz bir ad.
expression	String; required 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 hedefine karşılık gelir.
opts	List of strings; optional Sorgu motoruna geçirilen seçenekler. Bunlar, bazel query öğesine geçirilebilen 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çeneklerin, bazel query komut satırında olduğu gibi varsayılan değerleri olur.
scope	null; required Sorgunun kapsamı. Sorgunun, bu hedeflerin geçişli olarak kapatılmasının dışındaki hedeflere dokunmasına izin verilmez.
strict	Boolean; optional; default is True Doğru değerine ayarlanırsa sorguları kapsamlarının geçişli olarak kapatılmasından kaçan hedefler derlenemez. Yanlış değerine ayarlanırsa Bazel bir uyarı yazdırır ve sorgunun geri kalanını tamamlarken kapsamın dışına yönlendiren sorgu yolunu atlar.

Genrule

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, 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ı bir Bash komutu kullanarak bir veya daha fazla dosya oluşturur.

Kurallar, görev için belirli bir kural yoksa kullanabileceğiniz genel oluşturma kurallarıdır. Örneğin, tek satırlık bir Bash belgesi yayınlayabilirsiniz. Ancak C++ dosyalarını derlemeniz gerekiyorsa işin zor kısmını sizin yerinize zaten yapmış olduğunuzdan mevcut cc_* kurallarına bağlı kalın.

Test çalıştırmak için bir 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 mimaride çalıştırılması gerekir. Ancak, formüller derleme sırasında ve ana makine mimarisinde yürütülür (ikisi farklı olabilir). Genel amaçlı bir test kuralına ihtiyacınız varsa sh_test değerini kullanın.

Derlemeler Arasında Dikkat Edilmesi Gereken Noktalar

Çapraz derleme hakkında daha fazla bilgi için kullanıcı kılavuzuna bakın.

Genrule'lar derleme sırasında çalıştırılsa da çıkışları genellikle derlemeden sonra dağıtım veya test için kullanılır. Bir 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 kod, açıkçası onu oluşturmak için kullanılan CPU'da çalışamaz ancak C derleyicisinin (kaynaktan derlenmişse) bunu çalışması gerekir.

Derleme sistemi, derlemenin çalıştığı makineleri tanımlamak için ana makine yapılandırmasını, derleme çıktısının çalışması gereken makineleri tanımlamak için ise 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 için derleme sistemi, bağımlılıkların uygun şekilde oluşturulduğundan emin olur: target yapılandırması için srcs oluşturulur (gerekirse), tools host yapılandırması için oluşturulur ve çıkışın target yapılandırması için kullanıldığı kabul edilir. Ayrıca, genel komutların ilgili araçlara iletebileceği "Yap" değişkenleri de sağlar.

Genel kural, herhangi bir deps özelliğini tanımlamaz. Diğer yerleşik kurallar, bağımlı kuralların nasıl işleneceğini otomatik olarak belirlemek için kurallar arasında iletilen dile bağlı meta bilgileri kullanır. Ancak türler için bu düzeyde otomasyon mümkün değildir. Genrules yalnızca dosya ve runfiles düzeyinde çalışır.

Özel Durumlar

Ana makine-ana makine derlemesi: Bazı durumlarda, derleme sisteminin, çıkışın derleme sırasında da yürütülebilmesi için türleri çalıştırması gerekir. Örneğin bir genrule, daha sonra başka bir tür tarafından kullanılacak olan özel derleyici oluşturursa ilkinin ana makine yapılandırması için çıktısını oluşturması gerekir çünkü derleyici diğer genrule'da burada çalışır. Bu durumda, derleme sistemi doğru şeyi otomatik olarak yapar: Ana yapılandırma için hedef yapılandırma yerine ilk türün srcs ve outs öğelerini oluşturur. Daha fazla bilgi için kullanım kılavuzuna bakın.

JDK ve C++ Araçları: Derleme sistemi, JDK veya C++ derleyici paketindeki bir aracı kullanmak için kullanılacak değişken grubu sağlar. Ayrıntılar için "Oluşturma" değişkeni konusuna bakın.

Genrule Ortam

Genrule komutu, set -e -o pipefail kullanılarak 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 yürütülür.

Derleme aracı, Bash komutunu yalnızca PATH, PWD, TMPDIR ve diğer birkaç temel değişkeni tanımlayan arındırılmış işlem ortamında yürütür. Derlemelerin yeniden oluşturulabildiğinden emin olmak için kullanıcının kabuk ortamında tanımlanan çoğu değişken, genrule komutuna iletilmez. Bununla birlikte, Bazel (Blaze değil), kullanıcının PATH ortam değişkeninin değerini geçer. PATH değerinde herhangi bir değişiklik, Bazel'ın bir sonraki derlemede komutu yeniden çalıştırmasına neden olur.

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

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

Genel Tavsiye

• Bir türün yönettiği araçların deterministik ve hermetik olduğundan emin olun. Çıkışlarına zaman damgaları yazmamalı, kümeler ve haritalar için sabit bir sıralama kullanmalı, ayrıca çıkışa yalnızca göreli dosya yolları yazmalı, mutlak yol içermemelidir. Bu kurala uyulmaması, beklenmeyen derleme davranışına (Bazel'in düşündüğünüz gibi bir kuralı yeniden oluşturmamasına) neden olur ve önbellek performansını düşürür.
• Çıkışlar, araçlar ve kaynaklar için $(location) politikasını yoğun bir şekilde kullanın. Çıkış dosyalarının farklı yapılandırmalar için ayrılması nedeniyle, türler sabit kodlu ve/veya mutlak yollara dayanamaz.
• Aynı veya çok benzer türlerin birden fazla yerde kullanılması ihtimaline karşı ortak bir Starlark makrosu yazın. Oluşturma yöntemi karmaşıksa bunu bir komut dosyası veya Starlark kuralı olarak uygulamayı düşünebilirsiniz. Bu, okunabilirliği ve test edilebilirliği iyileştirir.
• Çıkış kodunun, genrule işleminin başarılı veya başarısız olduğunu doğru bir şekilde gösterdiğinden emin olun.
• stdout veya stderr'e bilgilendirici iletiler yazmayın. Hata ayıklama açısından faydalı olsa da bu, kolayca parazit haline gelebilir. Başarılı bir genrule 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).
• Sembolik bağlantılar ve dizinler oluşturmaktan kaçının. Bazel, Genrules tarafından oluşturulan dizin/sembolik bağlantı yapısını kopyalamaz ve dizinlerin bağımlılık kontrolü güvenilir değildir.
• Diğer kurallarda genel kurala referans verirken Genrule etiketini veya bağımsız çıkış dosyalarının etiketlerini kullanabilirsiniz. Bazen bir yaklaşım daha okunaklı olabilir, bazen diğer: Bir tüketim kuralının srcs öğesinde çıkışlara adla referans vermek, istemeden diğer genrule çıktılarının alınmasını önler, ancak genrule çok sayıda çıkış üretiyorsa yorucu olabilir.

Örnekler

Bu örnek, foo.h oluşturur. Komut herhangi bir giriş almadığı için kaynak yok. Komut tarafından çalıştırılan "binary", genrule ile aynı paketteki 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 öğesinin nasıl kullanılacağı ve başka bir genrule öğesinin çıktıları gösterilmektedir. Açık $(location) yönergeleri yerine $(SRCS) kullanmanın da işe yarayacağını unutmayın. Bu örnekte, açıklama amacıyla ikincisi 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	Name; required Bu hedef için benzersiz bir ad. Bu kurala, diğer BUILD kurallarının srcs veya deps bölümünde adını kullanarak başvurabilirsiniz. Kural kaynak dosyalar oluşturuyorsa srcs özelliğini kullanmanız gerekir.
srcs	List of labels; optional Bu kural için girişlerin listesi (ör. işlenecek kaynak dosyalar). Bu özellik, cmd tarafından yürütülen araçları listelemek için uygun değildir. Bunun yerine bunlar için tools özelliğini kullanın. Derleme sistemi, bu ön koşulların, genrule komutunu çalıştırmadan önce oluşturulmasını sağlar. Bu ön koşullar, orijinal derleme isteğiyle aynı yapılandırma kullanılarak oluşturulur. Bu ön koşullardaki dosyaların adları, komutta $(SRCS) içinde boşlukla ayrılmış liste olarak bulunur. Alternatif olarak, bağımsız bir srcs hedefinin //x:y yolu, $(location //x:y) veya srcs içindeki tek giriş olması koşuluyla $< kullanılarak alınabilir.
outs	List of filenames; required; nonconfigurable Bu kural tarafından oluşturulan dosyaların listesi. Çıkış dosyaları paket sınırlarını aşmamalıdır. Çı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 içinde türe özgü "Marka" değişkenleri ($@, $(OUTS), $(@D) veya $(RULEDIR)) kullanılarak veya $(location) değişikliği kullanılarak kullanılabilir.
cmd	String; optional Çalıştırılacak komut. $(location) ve "Yap" değişkeni değişikliğine tabidir. İlk $(location) değişikliği, $(location label) ve $(locations label) ile ilgili tüm tekrarların (ve execpath, execpaths, rootpath ve rootpaths alakalı değişkenlerini kullanan benzer yapılandırmaların) yerine getirilir. Ardından, "Yap" değişkenleri genişletilir. Önceden tanımlanmış $(JAVA), $(JAVAC) ve $(JAVABASE) değişkenlerinin ana makine yapılandırmasının altında genişlediğini unutmayın. Böylece bir 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. Son olarak, sonuçta elde edilen komut Bash kabuğu kullanılarak çalıştırı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 öğelerinin yedeğidir. Komut satırı uzunluğu platform sınırını aşarsa (Linux/macOS'te 64K, Windows'da 8K) genrule komutu bir komut dosyasına yazar ve sorunu çözmek için o komut dosyasını çalıştırır. Bu, tüm cmd özellikleri (cmd, cmd_bash, cmd_ps, cmd_bat) için geçerlidir.
cmd_bash	String; optional Çalıştırılacak Bash komutu. Bu özellik, cmd değerinden daha yüksek önceliğe sahip. Komut, genişletilir ve cmd özelliğiyle tam olarak aynı şekilde çalışır.
cmd_bat	String; optional Windows'da çalıştırılacak Batch komutu. Bu özellik, cmd ve cmd_bash özelliklerinden daha yüksek önceliğe sahip. Komut, aşağıdaki farklılıklarla birlikte cmd özelliğine benzer bir şekilde çalışır: Bu özellik yalnızca Windows'da geçerlidir. Komut, aşağıdaki varsayılan bağımsız değişkenlerle cmd.exe /c ile çalışır: /S - ilk ve son tırnak işaretlerini çıkarıp 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şletmesini etkinleştir /D - AutoRun kayıt defteri girişlerini yoksayın. $(location) ve "Make" değişkeni değişikliğinden sonra yollar Windows stili yollarıyla (ters eğik çizgiyle) genişletilir.
cmd_ps	String; optional Windows'da çalıştırılacak Powershell komutu. Bu özellik cmd, cmd_bash ve cmd_bat özelliklerinden daha yüksek önceliğe sahip. Komut, aşağıdaki farklılıklar dışında cmd özelliğine benzer bir şekilde çalışır: Bu özellik yalnızca Windows'da geçerlidir. Komut powershell.exe /c ile çalıştırılır. Powershell'i daha kolay kullanmak ve hataya daha az açık hale getirmek için genrule'da Powershell komutunu çalıştırmadan önce ortamı ayarlamak üzere aşağıdaki komutları çalıştırıyoruz. Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - imzasız komut dosyalarının çalıştırılmasına izin verir. $errorActionPreference='Stop': ; ile ayrılmış birden fazla komut varsa Powershell CmdLet başarısız olursa işlem hemen çıkar. Ancak bu, harici komutta ÇALIŞMAZ. $PSDefaultParameterValues['*:Encoding'] = 'utf8' - Varsayılan kodlamayı utf-16'dan utf-8'e değiştirin.
exec_tools	List of labels; optional Bu kurala ilişkin araç bağımlılıklarının listesi. Bu, tools özelliğiyle tam olarak aynı şekilde davranır ancak bu bağımlılıklar ana makine yapılandırması yerine kuralın yürütme platformu için yapılandırılır. Yani exec_tools içindeki bağımlılıklar, tools hizmetindeki bağımlılıklarla aynı sınırlamalara tabi değildir. Özellikle kendi geçişli bağımlılıkları için ana makine yapılandırmasını kullanmaları gerekmez. Daha fazla bilgi için tools sayfasını inceleyin. Blaze ekibi, tüm tools kullanımlarını exec_tools anlamlarını kullanacak şekilde taşıyor. Herhangi bir soruna neden olmayan kullanıcıların, tools yerine exec_tools ürününü tercih etmeleri önerilir. İşlevsel taşıma işlemi tamamlandıktan sonra exec_tools öğesini tools olarak yeniden adlandırabiliriz. Bu değişiklik yapılmadan önce desteği sonlandırma uyarısı ve taşıma talimatları gönderilir.
executable	Boolean; optional; nonconfigurable; default is False Çıkışın yürütülebilir olduğunu bildirin. Bu işaretin True (Doğru) değerine ayarlanması, çıkışı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 çıktı ü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 bildirilmesi desteklenmiyor.
local	Boolean; optional; default is False True (Doğru) değerine ayarlanırsa bu seçenek, bu genrule öğesini "yerel" stratejiyi kullanarak çalıştırmaya zorlar. Diğer bir deyişle, uzaktan yürütme, korumalı alan ve kalıcı çalışan olmaz. Bu, etiket olarak "local" (yerel) sağlamayla eşdeğerdir (tags=["local"]).
message	String; optional İlerleme durumu mesajı. Bu derleme adımı yürütüldüğünde yazdırılacak bir ilerleme mesajı. Varsayılan olarak mesaj, "Çıkış oluşturuluyor" (veya eşit derecede sıkıcı bir şey) şeklindedir ancak daha özel bir mesaj sağlayabilirsiniz. echo veya cmd komutunuzda bu özellik yerine bu özelliği kullanın. Bu şekilde, derleme aracı bu ilerleme mesajlarının yazdırılıp yazdırılmadığını kontrol edebilir.
output_licenses	Licence type; optional Şuna göz atın: common attributes
output_to_bindir	Boolean; optional; nonconfigurable; default is 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	List of labels; optional Bu kurala ilişkin 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, genel komutunu çalıştırmadan önce oluşturulmasını sağlar. Bu araçlar derlemenin parçası olarak yürütüldüğü için host yapılandırması kullanılarak oluşturulur. Bağımsız bir tools hedefinin //x:y yolu, $(location //x:y) kullanılarak elde edilebilir. Doğru yapılandırmada oluşturulduğundan emin olmak için cmd tarafından yürütülecek tüm *_binary veya araçlar srcs içinde değil, bu listede görünmelidir.

test_suite

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite, insanlar için "yararlı" olarak kabul edilen bir dizi testi tanımlar. Bu sayede projeler, "kontrol öncesinde çalıştırmanız gereken testler", "projemizin stres testleri" veya "tümü küçük testler" gibi test grupları tanımlayabilir. blaze test komutu şu tür bir organizasyona uyar: blaze test //some/test:suite gibi bir çağrı için Blaze, öncelikle //some/test:suite hedefinin içerdiği tüm test hedeflerini geçişli olarak sıralar (buna "test_suite genişletmesi" adını veririz), ardından Blaze bu hedefleri oluşturup test eder.

Örnekler

Mevcut paketteki tüm küçük testleri çalıştırmak için 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 güvenilir 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	Name; required Bu hedef için benzersiz bir ad.
tags	List of strings; optional; nonconfigurable "Küçük" veya "veritabanı" veya "-flaky" gibi metin etiketlerinin listesi. Etiketler geçerli herhangi bir dize olabilir. "-" karakteriyle başlayan etiketler negatif etiket olarak kabul edilir. Önceki "-" karakteri, etiketin bir parçası olarak kabul edilmez. Dolayısıyla, "-small" paketindeki bir etiket, testin "küçük" boyutuyla eşleşir. Diğer tüm etiketler pozitif etiket olarak kabul edilir. İsteğe bağlı olarak, pozitif etiketleri daha açık hale getirmek için etiketler "+" karakteriyle de başlayabilir. Bu, etiket metninin parçası olarak değerlendirilmez. Yalnızca pozitif ve negatif ayrımın daha kolay okunmasını sağlar. Test paketine yalnızca pozitif etiketlerin tümü ve negatif etiketlerin hiçbiri ile eşleşen test kuralları dahil edilir. Bunun, filtrelenen testlerde bağımlılık olup olmadığını kontrol eden hata kontrolünün atlandığı anlamına gelmediğini unutmayın.Atlanan testlere olan bağımlılıkların yine de yasal olması gerekir (ör. görünürlük kısıtlamaları tarafından engellenmemelidir). manual etiketi anahtar kelimesi, yukarıdakilerden farklı şekilde, joker karakter hedef kalıpları içeren çağrılarda blaze test komutu tarafından gerçekleştirilen "test_suite genişletmesi" tarafından işlenir. Burada, "manuel" etiketli test_suite hedef filtrelenir (ve dolayısıyla genişletilmez). Bu davranış, blaze build ve blaze test özelliklerinin genel olarak joker karakter hedef kalıplarını işleme şekliyle tutarlıdır. Paketler manual etiketinden bağımsız olarak her zaman tests sorgu işleviyle genişletildiğinden bunun blaze query 'tests(E)' davranışından açık bir şekilde farklı olduğunu unutmayın. Bir testin size değerinin, filtreleme amacıyla etiket olarak kabul edildiğini unutmayın. Karşılıklı birbirini dışlayan etiketlere sahip testler (örneğin, tüm küçük ve orta testler) içeren bir test_suite kuralına ihtiyacınız varsa üç test_suite kuralı oluşturmanız gerekir. Bu kural, tüm küçük testler için bir, tüm orta düzeydeki testler için bir ve önceki ikisini içeren bir kural olmalıdır.
tests	List of labels; optional; nonconfigurable Herhangi bir dildeki test paketleri ve test hedeflerinin listesi. Burada, dilden bağımsız olarak tüm *_test kabul edilir. Bununla birlikte, test çalıştırsa bile hiçbir *_binary hedefi kabul edilmez. Belirtilen tags değerine göre filtreleme, yalnızca doğrudan bu özellikte listelenen testler için yapılır. Bu özellikte test_suite varsa bunların içindeki testler bu test_suite tarafından filtrelenmez (zaten filtrelenmiş olarak kabul edilirler). tests özelliği belirtilmemişse veya boşsa kural varsayılan olarak, mevcut BUILD dosyasına manual olarak etiketlenmemiş tüm test kurallarını dahil eder. Bu kurallar yine tag filtrelemesine tabidir.