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ı, bir kural için kullanılabilecek başka bir ad oluşturur.

Takma ad, yalnızca "normal" hedefler için çalışır. Özellikle, package_group ve test_suite diğerlerine ad veremez.

Takma ad kuralının kendi görünürlük bildirimi vardır. Diğer tüm açılardan, referans verdiği kural gibi davranır (ör. takma addaki testonly göz ardı edilir; bunun yerine referans verilen kuralın salt test düzeyi kullanılır) ve bazı küçük istisnalar bulunur:

• Komut satırında takma adlarından bahsediliyorsa 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 işaret 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 select, genel özelliğe genel bakış için Yapılandırılabilir özelliklere bakın.

Örnekler

Aşağıdaki kod, --compilation_mode=opt veya -c opt değerlerini ayarlayan tüm derlemelerle 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ı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ğıdaki, kullanıcı tanımlı işareti --//custom_flags:foo=1 ayarlayan (açıkça komut satırında 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 örnekte, //example:glibc_2_25 etiketine sahip bir constraint_value bulunduğu varsayılarak x86_64 mimarisi ve glibc sürümü 2.25 olan bir platformu hedefleyen tüm derlemeler eşleştirilmektedir. Bir platformun, bu ikisinin dışında ek sınırlama değerleri tanımladığı durumlarda hâlâ eşleştirme yaptığını 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 atamadan farklı bir platform için oluşturulması gerekiyorsa. Bu, bir config_setting üst düzey komut satırı işaretleriyle eşleşmediğinde bile bazı derleme hedefleriyle eşleşebileceği anlamına gelir.

Notlar

• Mevcut yapılandırma durumuyla birden fazla config_setting eşleştiğinde ne olacağını öğrenmek için select (seçme) bölümüne bakın.
• Kısayol biçimlerini destekleyen işaretler (ör. --compilation_mode - -c) için values tanımlarının tam biçimi kullanması gerekir. 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 işareti gibi) "a" gerçek listede herhangi bir yerde mevcutsa values = { "flag": "a" } eşleşir.

  values = { "myflag": "a,b" } de 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 ü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) oluşturur: Hem -ios_multi_cpus=a,b hem de ios_multi_cpus=a --ios_multi_cpus=b ["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 modellenmemiş koşullar tanımlamanız gerekiyorsa Starlark tarafından tanımlanan işaretleri kullanın. --define yöntemini de kullanabilirsiniz ancak bu yöntem daha zayıf destek sağladığından önerilmez. Daha fazla bilgi için buraya göz atın.
• config_setting tanımlarını farklı paketlerde tekrarlamaktan kaçını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 herhangi bir config_setting için en az bir kombinasyon 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şmesi için hedef platformun belirtmesi gereken minimum constraint_values grubu. (Yürütme platformu burada dikkate alınmaz.) Platformun sahip olduğu ek kısıtlama değerleri yok sayılır. 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 için 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 geçerlidir. --define özeldir, çünkü söz dizimi (--define KEY=VAL) KEY=VAL'nin Bazel bayrağı açısından bir değer olduğu anlamına gelir. Bu durumda: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) çalışmaz. Çünkü aynı anahtar (define) sözlükte iki kez kullanılmıştır. 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 bir şekilde eşleşiyor. --define yine de normal işaret söz dizimiyle values içinde görünebilir ve sözlük anahtarları farklı kaldığı sürece bu özellikle serbestçe 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 flag'lere ise rastgele dizelere başvurulur.
values	Dictionary: String -> String; optional; nonconfigurable Bu kuralla eşleşen yapılandırma değerleri grubu (derleme bayrakları 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 girişin yapılandırması girişin beklenen değeriyle eşleşiyorsa 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ğlamak amacıyla, yapılandırma değerleri derleme bayrağı olarak belirtilir (önceki "--" olmadan). 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 ayarlanmazsa varsayılan değeri kullanılır. Bir anahtar, sözlükte birden çok kez görünürse yalnızca sonuncu ö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ş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 kullanışlı bir ad vermek için filegroup kullanın. Daha sonra bunlara diğer kurallardan referans verilebilir.

Doğrudan dizinlere referans vermek yerine filegroup kullanılması önerilir. İkinci yöntem, derleme sistemi dizin altındaki tüm dosyalar hakkında tam bilgiye sahip olmadığından bir çözüm bulmaz. Bu nedenle, bu dosyalar değiştiğinde yeniden oluşturmayabilir. filegroup, glob ile birlikte kullanıldığında 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 şunu yapın:

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

Veya bir testdata dizinini görüntülemek için glob kullanın:

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

Bu tanımlardan yararlanmak için herhangi bir kuraldan bir etiketle filegroup referansına başvurun:

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 bir 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 öğesine eklenir. filegroup öğesine başka bir kuralın data özelliğinde referans verildiğinde, öğenin runfiles öğesi bağlı kuralı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ünü ve data ile ilgili genel belgeleri inceleyin.
output_group	String; optional Kaynaklardan yapıların toplanacağı çıkış grubu. Bu özellik belirtilirse varsayılan çıkış grubu yerine belirtilen bağımlılıkların çıkış grubundaki yapılar dışa aktarılır. "Çıkış grubu", kuralın uygulamasında belirtilen, 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 atar.

Derlemenin tutarlı kalması için sorgunun yalnızca scope özelliğinde belirtilen hedeflerin geçişli olarak kapanması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 değeri yanlışsa kapsam dışı hedefler bir uyarıyla atlanır). Bunun olmamasını sağlamanın en kolay yolu, sorgu ifadesindekiyle aynı etiketleri kapsamda 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/..."] değerine izin verilmez).

Genquery'nin çıkışı, belirleyici çıkışı uygulamak için --order_output=full kullanılarak sıralanır.

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

Örnekler

Bu örnekte, belirtilen hedefin geçişli kapanışındaki etiketlerin listesi bir dosyaya yazılır.

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ının ve DERLEME 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 yer alan :b etiketi, //:b hedefine referans verir.
opts	List of strings; optional Sorgu motoruna geçirilen seçenekler. Bunlar, bazel query işlevine iletilebilecek 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 kapanması 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 kapanması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ı Bash komutu kullanarak bir veya daha fazla dosya oluşturur.

Kurallar, görev için belirli bir kural olmadığında kullanabileceğiniz genel derleme kurallarıdır. Örneğin, bir Bash tek satırlı metin yazabilirsiniz. Ancak C++ dosyalarını derlemeniz gerekiyorsa mevcut cc_* kurallarına bağlı kalın. İşin zor kısmını zaten sizin yerinize yapmışsınızdır.

Test çalıştırmak için genrule kullanmayın. Test 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. Kurallar, derleme sırasında ve ana makine mimarisinde yürütülür (ikisi farklı olabilir). Genel amaçlı test kuralına ihtiyacınız varsa sh_test kullanın.

Çapraz Derleme Hakkında Dikkat Edilmesi Gerekenler

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

Genel kurallar bir derleme sırasında çalışır ancak çıkışları genellikle derlemeden sonra dağıtım veya test için kullanılır. Bir mikro denetleyici için C kodu derleme örneğini düşünün: Derleyici, C kaynak dosyalarını kabul eder ve bir mikrodenetleyici üzerinde çalışan kod oluşturur. Oluşturulan kod açıkça bu CPU'yu oluşturmak için kullanılan CPU'da çalışamaz, ancak C derleyicisinin (kaynaktan derlenmişse) bunu yapması 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ırmak için seçenekler sunar ve çakışmaları önlemek için ilgili dosyaları ayrı dizinlere ayırır.

Genrules için derleme sistemi, bağımlılıkların uygun şekilde derlendiğinden 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 olduğu kabul edilir. Ayrıca, genel komutların ilgili araçlara geçirebileceği "Oluştur" değişkenleri de sağlar.

Genrule için herhangi bir deps özelliği tanımlanmamıştı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 bu düzeyde bir otomasyon, Genrules için mümkün değildir. Genel kurallar yalnızca dosya ve çalıştırma dosyaları 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ürler çalıştırması gerekir. Örneğin, bir genrule, daha sonra başka bir tür tarafından kullanılacak olan bir ö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 olanı otomatik olarak yapar: Hedef yapılandırma yerine ana makine yapılandırması için birinci türünün srcs ve outs öğelerini oluşturur. Daha fazla bilgi için kullanım kılavuzuna bakın.

JDK ve C++ Araçları: JDK veya C++ derleyici paketinden bir araç kullanmak için derleme sistemi, kullanılacak bir dizi değişken sağlar. Ayrıntılar için "Marka" değişkenine bakın.

Genrule Ortam

Genrule komutu, bir komut veya ardışık düzen başarısız olduğunda set -e -o pipefail kullanılarak başarısız olacak şekilde yapılandırılan Bash kabuğu tarafından çalıştırı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şturulabilir olduğundan 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çirir. PATH değerindeki herhangi bir değişiklik, Bazel'ın bir sonraki derlemede komutu yeniden çalıştırmasına neden olur.

genrule komutu, şu anda zorunlu olmasa da 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 genel kuralı çalıştırmadan önce gerekli üst dizinleri oluşturur. Ayrıca, hata durumunda tüm çıkış dosyalarını kaldırır.

Genel Tavsiye

• Ciddi bir kural tarafından yönetilen 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 yol olmamalı ve çıkışa yalnızca göreli dosya yolları yazmalıdırlar. Bu kurala uyulmaması, beklenmeyen bir derleme davranışına (Bazel'in düşündüğünüz bir biçimi yeniden oluşturmamasına) neden olur ve önbellek performansını düşürür.
• Çıktılar, araçlar ve kaynaklar için $(location) uygulamasını yaygın olarak kullanın. Çıkış dosyalarının farklı yapılandırmalar için ayrılması nedeniyle, türler sabit kodlu ve/veya mutlak yollara dayanamaz.
• Birden çok yerde aynı veya çok benzer türlerin kullanılması ihtimaline karşı ortak bir Starlark makrosu yazın. Genrule karmaşıksa bunu bir komut dosyası veya Starlark kuralı olarak uygulamayı düşünebilirsiniz. Bu, okunabilirliği ve test edilebilirliği iyileştirir.
• Çıkış kodunun, oluşturma işleminin başarılı veya başarısız olduğunu doğru bir şekilde belirttiğinden emin olun.
• stdout veya stderr'a bilgilendirici iletiler yazmayın. Bu, hata ayıklama açısından faydalı olsa da kolayca gürültüye dönüşebilir. Başarılı bir oluşturma işlemi sessiz olmalıdır. Öte yandan başarısız bir nazik davranış, 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).
• Simgesel 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 denetimi güvenilir değildir.
• Diğer kurallarda genrule özelliğine referans verirken genrule etiketini veya bağımsız çıkış dosyalarının etiketlerini kullanabilirsiniz. Bazen bir yaklaşım daha okunabilir, bazen de diğer: bir tüketim kuralının srcs öğesinde çıktılara adla atıfta bulunmak, genrule türünün diğer çıktılarını istemeden almaktan kaçınır, ancak genrule çok sayıda sonuç üretiyorsa yorucu olabilir.

Örnekler

Bu örnek, foo.h sonucunu oluşturur. Komut herhangi bir giriş almadığı için kaynak yok. Komutun çalıştırdığı "binary", 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, bir filegroup öğesinin nasıl kullanılacağı ve başka bir genrule öğesinin sonuçları gösterilmektedir. Açık $(location) yönergeleri yerine $(SRCS) kullanmanın da işe yarayacağını unutmayın. Bu örnekte göstermek amacıyla ikinci kural kullanılmıştı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ıyla başvurabilirsiniz. Kural, kaynak dosyalar oluşturuyorsa srcs özelliğini kullanmanız gerekir.
srcs	List of labels; optional Bu kural için giriş listesi (ör. işlenecek kaynak dosyalar). Bu özellikler, cmd tarafından yürütülen araçları listelemek için uygun değildir. Bunlar için tools özelliğini kullanın. Derleme sistemi, genel komutunu çalıştırmadan önce bu önkoşulların derlenmesini sağlar. Bunlar, orijinal derleme isteğiyle aynı yapılandırma kullanılarak derlenir. Bu önkoşullara sahip dosyaların adları, komutta $(SRCS) içinde boşlukla ayrılmış liste olarak bulunur. Alternatif olarak tek bir srcs hedef //x:y yolunun 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. Çıktı dosyaları paket sınırlarını aşmamalıdır. Çıkış dosya adları pakete göre yorumlanır. executable işareti ayarlanmışsa outs tam olarak bir etiket içermelidir. Genrule komutunun her çıkış dosyasını önceden belirlenmiş bir konumda oluşturması beklenir. Konum, cmd içinde genel kurala özel "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 "Değişken yap" değişikliğine tabidir. İlk $(location) değişikliği, $(location label) ve $(locations label) özelliklerinin tamamı (ve execpath, execpaths, rootpath ve rootpaths ilişkili değişkenlerini kullanan benzer yapılar) değiştirilerek uygulanır. Daha sonra, "Marka" 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. Bu nedenle, 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 komut başarısız olmuş kabul edilir. Bu, hiçbiri geçerli değilse cmd_bash, cmd_ps ve cmd_bat yedekleridir. 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 geçici çözüm için o 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	String; optional Çalıştırılacak Bash komutu. Bu özellik, cmd özelliğine göre daha yüksek önceliğe sahip. Komut genişletilir ve cmd özelliğiyle 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ıklar dışında cmd özelliğine benzer bir şekilde çalışır: Bu özellik yalnızca Windows'da geçerlidir. Komut, cmd.exe /c ile aşağıdaki varsayılan bağımsız değişkenlerle çalışır: /S - ilk ve son tırnak işaretlerini çıkarıp diğer her şeyi olduğu gibi yürütür. /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ına (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 şekilde çalışır: Bu özellik yalnızca Windows'da geçerlidir. Komut, powershell.exe /c ile çalışır. Powershell'in kullanımını kolaylaştırmak ve hataya daha az açık olması için aşağıdaki komutları çalıştırarak Powershell komutunu genrule'da çalıştırmadan önce ortamı ayarlı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 olduğunda, Powershell CmdLet başarısız olursa işlem hemen çıkar. Ancak bu, harici komut için ÇALIŞMAZ. $PSDefaultParameterValues['*:Encoding'] = 'utf8' - utf-16 olan varsayılan kodlamayı utf-8 olarak değiştirin.
exec_tools	List of labels; optional Bu kuralın araç bağımlılıklarının bir listesi. Bu bağımlılıklar ana makine yapılandırması yerine kuralın yürütme platformu için yapılandırılacak olması dışında, tam olarak tools özelliğiyle aynı şekilde davranı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 semantiğini kullanacak şekilde taşıyor. Herhangi bir soruna neden olmayan durumlarda, kullanıcıların exec_tools yerine tools seçeneğini tercih etmeleri önerilir. İşlevsel taşıma işlemi tamamlandıktan sonra exec_tools adını tools olarak değiştirebiliriz. Bu değişiklik yapılmadan önce desteği sonlandırma uyarısı ve taşıma talimatları gönderilecektir.
executable	Boolean; optional; nonconfigurable; default is False Çıkışı 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ği ne olursa olsun 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. Yani, uzaktan yürütme, korumalı alan oluşturma ve kalıcı çalışan olmaz. Bu, etiket (tags=["local"]) olarak "local" sağlamakla eşdeğerdir.
message	String; optional İlerleme mesajı. Bu derleme adımı yürütüldüğünde yazdırılacak bir ilerleme mesajı. Varsayılan olarak, mesaj "çıktı oluşturuluyor" (veya eşit derecede sıkıcı bir mesaj) şeklindedir ancak daha spesifik bir mesaj sağlayabilirsiniz. Bu özelliği, derleme aracının bu ilerleme mesajlarının yazdırılıp yazdırılmayacağını kontrol etmesine olanak tanımak için echo veya cmd komutunuzda diğer yazılı ifadeler yerine bu özelliği kullanın.
output_licenses	Licence type; optional Bkz. 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 kuralın araç bağımlılıklarının bir listesi. Daha fazla bilgi için dependencies tanımına bakın. Derleme sistemi, bu ön koşulların genel komutunu çalıştırmadan önce derlenmesini sağlar. Bu araçlar derlemenin parçası olarak yürütüldüğü için host yapılandırması kullanılarak oluşturulur. Tek bir tools hedefinin yolu //x:y, $(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 bu listede görünmelidir (srcs listesinde görünmemelidir).

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 sürecinden önce çalıştırmanız gereken testler", "projemizin stres testleri" veya "tüm küçük testler" gibi test kümeleri tanımlayabilir. blaze test komutu bu tür bir organizasyona uyar: blaze test //some/test:suite gibi bir çağrıda Blaze, öncelikle //some/test:suite hedefi tarafından geçişli olarak eklenen tüm test hedeflerini numaralandırır (buna "test_suite genişletmesi" denir) ve daha sonra Blaze bu hedefleri oluşturup test eder.

Örnekler

Mevcut paketteki tüm küçük testleri çalıştırmak için kullanılan bir test paketi.

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

Belirli bir test grubunu çalıştıran 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. Öncesindeki "-" karakteri, etiketin bir parçası olarak kabul edilmez. Bu nedenle, "-small" paketinin etiketi bir testin "small" 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 bir parçası olarak değerlendirilmez. Yalnızca pozitif ve negatif ayrımların daha kolay okunmasını sağlar. Yalnızca pozitif etiketlerin tümü ile 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 için 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, 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 (ve bu nedenle genişletilmez). Bu davranış, blaze build ve blaze test özelliklerinin genel olarak joker karakter hedef kalıplarını işleme biçimiyle 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. Testin size değerinin, filtreleme amacıyla etiket olarak kabul edildiğini unutmayın. Karşılıklı birbirini dışlayan etiketler (ör. tüm küçük ve orta testler) içeren testler içeren bir test_suite öğesine ihtiyacınız varsa üç test_suite kuralı oluşturmanız gerekir: tüm küçük testler için bir, tüm orta düzey testler için bir ve önceki ikisini içeren bir kural.
tests	List of labels; optional; nonconfigurable Herhangi bir dildeki test paketlerinin ve test hedeflerinin listesi. Dilden bağımsız olarak tüm *_test burada kabul edilir. Bununla birlikte, test çalıştırılsa 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 özellik test_suite içeriyorsa içindeki testler bu test_suite tarafından filtrelenmez (zaten filtrelenmiş kabul edilir). 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 hâlâ tag filtrelemesine tabidir.