Genel Kurallar

Kurallar

• takma ad
• config_setting
• filegroup
• 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 atıfta bulunabileceği başka bir ad oluşturur.

Takma adlar yalnızca "normal" hedefler için çalışır. Özellikle package_group ve test_suite için takma ad kullanılamaz.

Takma ad kuralının kendi görünürlük beyanı vardır. Diğer tüm açılardan, referans verdiği kural gibi davranır (ör. takma ad üzerinde testonly yoksayılır; bunun yerine, referans verilen kuralın testonly özelliği kullanılır) ancak bazı küçük istisnalar vardır:

• Komut satırında takma adlarından bahsedilen testler çalıştırılmaz. Referans verilen testi çalıştıran bir takma ad tanımlamak için tests özelliğinde tek bir hedefi olan bir test_suite kuralını kullanın.
• Ortam grupları tanımlanırken environment kurallarının takma adları desteklenmez. --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 atıfta bulunduğu 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 işaretleri veya platform kısıtlamaları olarak ifade edilir) eşleşir. Bu kuralı nasıl kullanacağınızı öğrenmek için select'e, genel özelliğe genel bakış için ise Configurable attributes (Yapılandırılabilir özellikler) başlıklı makaleye bakın.

Örnekler

Aşağıdakiler, --compilation_mode=opt veya -c opt değerini ayarlayan tüm derlemelerle eşleşir (komut satırında açıkça veya .bazelrc dosyalarından dolaylı olarak):

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

Aşağıdaki ifade, ARM'i hedefleyen ve özel tanımlama FOO=bar'yi (örneğin, bazel build --cpu=arm --define FOO=bar ...) uygulayan tüm derlemelerle eşleşir:

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

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

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

Aşağıdaki ifade, //example:glibc_2_25 etiketli bir constraint_value bulunduğu varsayılarak x86_64 mimarisi ve glibc 2.25 sürümüne sahip bir platformu hedefleyen tüm derlemelerle eşleşir. Bir platformun, bu ikisinin dışında ek kısıtlama değerleri tanımlaması durumunda 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, yapılandırmanın derleme sırasında değişmesi mümkündür (ör. bir hedefin, dep'sinden 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

• Birden fazla config_setting mevcut yapılandırma durumuyla eşleştiğinde ne olacağı için select işlevine bakın.
• Kısaltma biçimlerini destekleyen işaretler (ör. --compilation_mode ve -c) için values tanımlarında tam biçim kullanılmalıdır. Bu çağrılar, her iki formu da kullanarak otomatik olarak eşleştirilir.
• Bir işaret birden fazla değer alıyorsa (--copt=-Da --copt=-Db veya liste türüne sahip bir Starlark işareti gibi) values = { "flag": "a" }, "a" gerçek listede herhangi bir yerde varsa 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. Tam anlamlar, işaretler arasında değişir. Örneğin, --copt aynı örnekte birden çok değeri desteklemez: --copt=a,b ["a,b"], --copt=a --copt=b ise ["a", "b"] değerini döndürür (bu nedenle values = { "copt": "a,b" }, birinciyle eşleşir ancak ikinciyle eşleşmez). Ancak --ios_multi_cpus (Apple kuralları için) böyledir: -ios_multi_cpus=a,b ve ios_multi_cpus=a --ios_multi_cpus=b her ikisi de ["a", "b"] değerini döndürür. Tam olarak ne beklediğinizi doğrulamak için işaret tanımlarını kontrol edin ve koşullarınızı dikkatlice test edin.

• Yerleşik derleme işaretleriyle modellenmeyen koşulları tanımlamanız gerekiyorsa Starlark tarafından tanımlanan işaretleri kullanın. --define değerini de kullanabilirsiniz ancak bu yöntem daha az destek sunar ve önerilmez. Daha fazla bilgi için buraya göz atın.
• Farklı paketlerde aynı config_setting tanımlarını tekrarlamaktan kaçının. Bunun yerine, standart bir pakette tanımlanan ortak bir config_setting'ye referans verin.
• 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 biri 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 Hedef platformun bu config_setting ile eşleşebilmesi için belirtmesi gereken minimum constraint_values grubu. (Yürütme platformu burada dikkate alınmaz.) Platformun sahip olduğu ek kısıtlama değerleri yoksayılır. Ayrıntılar için Yapılandırılabilir Derleme Özellikleri başlıklı makaleyi inceleyin. İki config_setting'nin aynı select ile eşleştiği durumlarda, bu özellik config_setting'lerden birinin diğerinin uzmanlık alanı 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ı ancak özellikle --define işareti için. --define, söz dizimi (--define KEY=VAL) nedeniyle özeldir çünkü KEY=VAL, Bazel işareti açısından bir değer Bu şu anlama gelir: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) aynı anahtar (define) sözlükte iki kez göründüğü için çalışmaz. Bu özellik bu 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şir. --define, normal işaret söz dizimi ile values içinde görünmeye devam edebilir 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 kullanılır. Kullanıcı tanımlı işaretler etiket olarak, yerleşik işaretler ise rastgele dize olarak referans verildiğinden bu farklı bir özelliktir.
values	Dictionary: String -> String; optional; nonconfigurable 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ı girişin beklenen değeriyle eşleşirse sözlüğün Bazel çağrısıyla "eşleştiği" 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, yapılandırma işaretleri olarak belirtilir (önceki "--" olmadan). Ancak bu iki değerin aynı olmadığını unutmayın. Bunun nedeni, hedeflerin aynı derleme içinde 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 ile eşleşir. Bu nedenle, aynı config_setting'nin farklı örnekleri, bunları kullanan kuralın yapılandırmasına bağlı olarak aynı çağrıyla farklı şekilde eşleşebilir. Komut satırında açıkça ayarlanmayan işaretler için varsayılan değer 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 herhangisi 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 simgesini kullanın. Bu değerler daha sonra diğer kurallardan referans verilerek kullanılabilir.

Dizinlere doğrudan referans vermek yerine filegroup kullanılması önerilir. Derleme sistemi, dizinin altındaki tüm dosyalarla ilgili tam bilgiye sahip olmadığından bu yöntem doğru değildir. Bu nedenle, bu dosyalar değiştiğinde yeniden derleme yapılmayabilir. filegroup, glob ile birlikte kullanıldığında tüm dosyaların derleme sisteminin açıkça bildiğinden emin olabilir.

Örnekler

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

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

Dilerseniz test verileri dizininde arama yapmak için glob kullanabilirsiniz:

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

Bu tanımları kullanmak için filegroup'e herhangi bir kuraldan etiketle referans verin:

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 üyeleri olan hedeflerin listesi. srcs özelliğinin değeri için glob ifadesinin sonucunun kullanılması yaygındır.
data	List of labels; optional Bu kuralın çalışma zamanında ihtiyaç duyduğu dosyaların listesi. data özelliğinde adlandırılan hedefler, bu filegroup kuralının runfiles bölümüne eklenir. Başka bir kuralın data özelliğinde filegroup'ye referans verildiğinde, filegroup'nin runfiles özelliği, bağlı kuralın runfiles özelliğine eklenir. Veri dosyalarına bağımlı olma ve bu dosyaları kullanma hakkında daha fazla bilgi için veri bağımlılıkları bölümünü ve data ile ilgili genel dokümanları inceleyin.
output_group	String; optional Kaynaklardan yapıların toplanacağı çıkış grubu. Bu özellik belirtilirse varsayılan çıkış grubu yerine, bağımlılıkların belirtilen çıkış grubundaki yapı taşları dışa aktarılır. "Çıkış grubu", bir kuralın uygulanması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ı kalması için sorgunun yalnızca scope özelliğinde belirtilen hedeflerin geçirgen kapatılmasını ziyaret etmesine izin verilir. strict belirtilmezse veya doğruysa bu kuralı ihlal eden sorgular yürütme sırasında başarısız olur (strict yanlışsa kapsam dışındaki hedefler bir uyarıyla atlanır). Bunun olmasını önlemenin en kolay yolu, kapsamda sorgu ifadesiyle aynı etiketlerden bahsetmektir.

Burada izin verilen sorgularla komut satırında izin verilen sorgular arasındaki tek fark, burada joker karakter hedefi spesifikasyonları (ör. //pkg:* veya //pkg:all) içeren sorgulara izin verilmemesidir. Bunun iki nedeni vardır: Birincisi, genquery'ün, sorgunun geçişli kapatma işleminin dışındaki hedeflerin çıktısını etkilemesini önlemek için bir kapsam belirtmesi gerekir.İkincisi, BUILD dosyaları joker karakter bağımlılıkları desteklemez (ör. deps=["//a/..."]'ye izin verilmez).

genquery'nin çıkışı, deterministik çıkışı zorunlu kılmak 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 kapatma işlemindeki 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 BUILD dosyalarındaki diğer yerlerin aksine, buradaki etiketler çalışma alanının kök dizine göre çözülür. Örneğin, a/BUILD dosyasındaki bu özellikteki :b etiketi, //:b hedefini referans alır.
opts	List of strings; optional Sorgu motoruna iletilen seçenekler. Bunlar, bazel query'e 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çenekler, bazel query komut satırındaki varsayılan değerlerine sahip olur.
scope	null; required Sorgunun kapsamı. Sorgunun, bu hedeflerin geçişli kapatma işleminin dışındaki hedeflere dokunmasına izin verilmez.
strict	Boolean; optional; default is True Doğru ise sorguları kapsamlarının geçişli kapatma işleminden kaçan hedefler oluşturulamaz. Yanlış ise Bazel bir uyarı yazdırır ve sorgunun geri kalanını tamamlarken kendisini kapsamın dışına çıkaran 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.

Genrules, görev için belirli bir kural yoksa kullanabileceğiniz genel derleme kurallarıdır. Örneğin, tek satırlık bir Bash komutu çalıştırabilirsiniz. Ancak C++ dosyalarını derlemeniz gerekiyorsa tüm ağır işler sizin için zaten yapıldığından mevcut cc_* kurallarına uyun.

Test çalıştırmak için genrule kullanmayın. Testler ve test sonuçları için önbelleğe alma politikaları ve ortam değişkenleri dahil olmak üzere özel muafiyetler vardır. Testlerin genellikle derleme tamamlandıktan sonra ve hedef mimaride çalıştırılması gerekir. Buna karşılık, genrules derleme sırasında ve ana mimaride (ikisi farklı olabilir) yürütülür. Genel amaçlı bir test kuralına ihtiyacınız varsa sh_test değerini kullanın.

Çapraz Derlemeyle İlgili Konular

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

genrules, derleme sırasında çalıştırılır ancak çıktıları genellikle derlemeden sonra dağıtım veya test için kullanılır. Bir mikrodenetleyici için C kodunu derleme örneğini düşünün: Derleyici, C kaynak dosyalarını kabul eder ve mikrodenetleyicide çalışan kod oluşturur. Oluşturulan kod, derlenmesi için kullanılan CPU'da çalışamaz ancak C derleyicisinin (kaynaktan derlenmişse) çalışması gerekir.

Derleme sistemi, derlemenin çalıştırıldığı makineleri tanımlamak için ana makine yapılandırmasını, derlemenin çıktısının çalıştırılması 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 ilgili dosyaları ayrı dizinlere ayırır.

Derleme sistemi, genrules için bağımlılıkların uygun şekilde derlendiğinden emin olur: srcs, hedef yapılandırması için (gerekirse) derlenir, tools, ana makine yapılandırması için derlenir ve çıkışın hedef yapılandırması için olduğu kabul edilir. Ayrıca, genrule komutlarının ilgili araçlara iletebileceği "Make" değişkenleri de sağlar.

genrule'un deps özelliğini tanımlamaması bilinçli bir seçimdir: Diğer yerleşik kurallar, bağımlı kuralların nasıl işleneceğini otomatik olarak belirlemek için kurallar arasında aktarılan dile bağlı meta bilgileri kullanır ancak genrules için bu düzeyde otomasyon mümkün değildir. Genrules yalnızca dosya ve çalıştırılabilir dosya 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 genrules'i çalıştırması gerekir. Örneğin, bir genrule daha sonra başka bir genrule tarafından kullanılan bazı özel derleyiciler oluşturursa ilk genrule'ün, derleyicinin diğer genrule'de çalışacağı yer olduğu için çıkışını ana makine yapılandırması için üretmesi gerekir. Bu durumda, derleme sistemi otomatik olarak doğru işlemi yapar: İlk genrule'nin srcs ve outs öğelerini hedef yapılandırma yerine ana makine yapılandırması için 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 "Marka" değişkeni bölümüne 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 bir Bash kabuğu tarafından yürütülür.

Derleme aracı, Bash komutunu yalnızca PATH, PWD, TMPDIR gibi temel değişkenleri tanımlayan, temizlenmiş bir işlem ortamında yürütür. Derlemelerin yeniden üretilebilir olmasını sağlamak için kullanıcının kabuk ortamında tanımlanan çoğu değişken, genrule komutuna iletilmez. Ancak Bazel (Blaze değil) kullanıcının PATH ortam değişkeninin değerini iletir. PATH değerinde yapılan herhangi bir değişiklik, Bazel'in bir sonraki derlemede komutu yeniden yürütmesine neden olur.

genrule komutu, komutun alt işlemleri olan işlemleri bağlamak dışında ağa erişmemelidir. Ancak bu şu anda zorunlu kılınmamıştır.

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

Genel Tavsiye

• Bir genrule 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 kararlı sıralama kullanmalı ve çıkışa yalnızca göreli dosya yolları yazmalı, mutlak yollar yazmamalıdır. Bu kurala uyulmaması, beklenmedik derleme davranışlarına (Bazel, yeniden oluşturacağınızı düşündüğünüz bir genrule'yi yeniden oluşturmaz) neden olur ve önbellek performansını düşürür.
• Çıkışlar, araçlar ve kaynaklar için $(location)'ü yoğun şekilde kullanın. Çıkış dosyalarının farklı yapılandırmalar için ayrılması nedeniyle genrules, kodlanmış ve/veya mutlak yollara güvenemez.
• Aynı veya çok benzer genrules'ın birden fazla yerde kullanılması ihtimaline karşı ortak bir Starlark makrosu yazın. genrule karmaşıksa bir komut dosyası veya Starlark kuralı olarak uygulamayı düşünebilirsiniz. Bu, okunabilirliğin yanı sıra test edilebilirliği de artırır.
• Çıkış kodunun, genrule'ın başarılı veya başarısız olduğunu doğru şekilde belirttiğinden emin olun.
• Bilgilendirme mesajlarını stdout veya stderr'ye yazmayın. Hata ayıklama için yararlı olsa da bu, kolayca gürültüye dönüşebilir. Başarılı bir genrule sessiz olmalıdır. Öte yandan, başarısız bir genrule 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).
• Simge bağlantısı ve dizin oluşturmaktan kaçının. Bazel, genrules tarafından oluşturulan dizin/yönlendirme bağlantısı yapısını kopyalamamakta ve dizinlerdeki bağımlılık kontrolü güvenilir değildir.
• Diğer kurallarda genrule'ye referans verirken genrule'nin etiketini veya ayrı çıkış dosyalarının etiketlerini kullanabilirsiniz. Bazen bir yaklaşım daha okunaklı, bazen de diğeri daha okunaklı olur: Tüketen kuralın srcs bölümünde çıkışlara isme göre referans vermek, gen kuralın diğer çıkışlarının yanlışlıkla alınmasını önler ancak gen kural çok fazla çıkış üretiyorsa can sıkıcı olabilir.

Örnekler

Bu örnek foo.h değerini döndürür. Komut herhangi bir giriş almadığı için kaynak yoktur. Komut tarafından çalıştırılan "ikili", 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, bir filegroup ve başka bir genrule'ın çıkışlarının nasıl kullanılacağı gösterilmektedir. Açık $(location) yönergeleri yerine $(SRCS) kullanılmasının da işe yarayacağını unutmayın. Bu örnekte, açıklama amacıyla açık yönergeler 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ünden adıyla referans verebilirsiniz. Kural kaynak dosyalar oluşturuyorsa srcs özelliğini kullanmanız gerekir.
srcs	List of labels; optional Bu kurala ait girişlerin listesi (ör. işlenecek kaynak dosyalar). Bu özellik, cmd tarafından çalıştırılan araçları listelemek için uygun değildir. Bunun yerine tools özelliğini kullanın. Derleme sistemi, genrule komutu çalıştırılmadan önce bu ön koşulların derlendiğinden emin olur. Bu ön koşullar, orijinal derleme isteğiyle aynı yapılandırma kullanılarak derlenir. Bu ön koşulların dosya adları, komut tarafından $(SRCS) içinde boşlukla ayrılmış bir liste olarak kullanılabilir. Alternatif olarak, tek bir srcs hedefi //x:y'nin yolu $(location //x:y) kullanılarak veya srcs'teki tek giriş olması koşuluyla $< kullanılarak elde edilebilir.
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ış dosyası 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 gen kuralına özgü "Make" değişkenleri ($@, $(OUTS), $(@D) veya $(RULEDIR)) kullanılarak ya da $(location) yerine koyma işlemi kullanılarak kullanılabilir.
cmd	String; optional Çalıştırılacak komut. $(location) ve "Make" değişkeni yerine koyma işlemine tabidir. İlk olarak $(location) ikame uygulanır. Bu işlemde $(location label) ve $(locations label)'in (ve ilgili execpath, execpaths, rootpath ve rootpaths değişkenlerini kullanan benzer yapıların) tüm oluşumları değiştirilir. Ardından, "Make" değişkenleri genişletilir. Önceden tanımlanmış $(JAVA), $(JAVAC) ve $(JAVABASE) değişkenlerinin ana makine yapılandırması altında genişletildiğini unutmayın. Böylece, derleme adımı kapsamında çalıştırılan Java çağrıları, paylaşılan kitaplıkları ve diğer bağımlılıkları doğru şekilde yükleyebilir. Son olarak, oluşturulan komut Bash kabuğu kullanılarak yürütülür. Çıkış kodu sıfırdan farklıysa komutun başarısız olduğu kabul edilir. Bu, cmd_bash, cmd_ps ve cmd_bat'ın hiçbiri geçerli değilse bu değerlerin yedeğidir. Komut satırı uzunluğu platform sınırını (Linux/macOS'te 64 KB, Windows'ta 8 KB) aşarsa genrule, komutu bir komut dosyasına yazar ve bu sorunu gidermek için komut dosyasını yürütür. Bu durum 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 özelliğin önceliği cmd özelliğinden daha yüksektir. Komut genişletilir ve cmd özelliğiyle tam olarak aynı şekilde çalışır.
cmd_bat	String; optional Windows'da çalıştırılacak toplu komut. Bu özelliğin önceliği cmd ve cmd_bash özelliklerinden daha yüksektir. Komut, cmd özelliğiyle benzer şekilde çalışır ancak aşağıdaki farklılıklar vardır: Bu özellik yalnızca Windows'ta geçerlidir. Komut, aşağıdaki varsayılan bağımsız değişkenlerle cmd.exe /c ile çalışır: /S: İlk ve son tırnak işaretlerini kaldırır ve diğer her şeyi olduğu gibi yürütür. /E:ON: Genişletilmiş komut setini etkinleştirin. /V:ON - gecikmeli değişken genişletmeyi etkinleştir /D: AutoRun kayıt defteri girişlerini yoksay. $(location) ve "Make" değişkeni yerine geçirildikten sonra yollar, Windows tarzı yollara (ters eğik çizgiyle) genişletilir.
cmd_ps	String; optional Windows'da çalıştırılacak PowerShell komutu. Bu özelliğin önceliği cmd, cmd_bash ve cmd_bat'den daha yüksektir. Komut, cmd özelliğine benzer şekilde çalışır ancak aşağıdaki farklılıklar vardır: Bu özellik yalnızca Windows'ta geçerlidir. Komut powershell.exe /c ile çalışır. Powershell'in kullanımının daha kolay ve hata olasılığının daha az olmasını sağlamak için genrule'da Powershell komutunu yürütmeden önce ortamı ayarlamak üzere aşağıdaki komutları çalıştırırız. Set-ExecutionPolicy -Scope CurrentUser RemoteSigned - imzasız komut dosyalarının çalıştırılmasına izin verin. $errorActionPreference='Stop': ; ile ayrılmış birden fazla komut varsa bir Powershell CmdLet başarısız olursa işlem hemen sonlandırılır ancak bu, harici komut için ÇALIŞMAZ. $PSDefaultParameterValues['*:Encoding'] = 'utf8': Varsayılan kodlamayı utf-16'dan utf-8'e değiştirin.
exec_tools	List of labels; optional Bu kuralın araç bağımlılıkları listesi. Bu özellik, tools özelliğiyle tam olarak aynı şekilde çalışır. Tek fark, bu bağımlıların ana makine yapılandırması yerine kuralın yürütme platformu için yapılandırılmasıdır. Bu, exec_tools'teki bağımlılıkların tools'teki bağımlılıklarla aynı sınırlamalara tabi olmadığı anlamına gelir. Özellikle, kendi geçişli bağımlılıklarında ana makine yapılandırmasını kullanmaları gerekmez. Daha fazla bilgi için tools bölümüne bakın. Blaze ekibi, tools'ün tüm kullanımlarını exec_tools semantiklerini kullanacak şekilde taşıyor. Kullanıcıların, herhangi bir soruna neden olmadığı durumlarda exec_tools yerine tools seçmesi önerilir. İşlevsel taşıma işlemi tamamlandıktan sonra exec_tools'ü tools olarak yeniden adlandırabiliriz. Bu değişiklikten önce desteğin sonlandırılmasıyla ilgili bir uyarı ve taşıma talimatları alırsınız.
executable	Boolean; optional; nonconfigurable; default is False Çıktıyı yürütülebilir olarak tanımlayın. Bu işaret True (Doğru) değerine ayarlanırsa çıktının yürütülebilir bir dosya olduğu ve run komutu kullanılarak çalıştırılabileceği anlaşılır. Bu durumda genrule tam olarak bir çıkış oluşturmalıdır. Bu özellik ayarlanırsa run, içeriğinden bağımsız olarak dosyayı yürütmeye çalışır. Oluşturulan yürütülebilir dosya için veri bağımlılıkları beyan etmek desteklenmez.
local	Boolean; optional; default is False Doğru değerine ayarlanırsa bu seçenek, genrule'ün "yerel" stratejiyi kullanarak çalıştırılmasını zorunlu kılar. Bu durumda uzaktan yürütme, korumalı alan ve kalıcı çalışanlar kullanılamaz. Bu, etiket olarak "local" (tags=["local"]) sağlamaya eşdeğerdir.
message	String; optional İlerleme mesajı. Bu derleme adımı yürütülürken yazdırılacak bir ilerleme mesajı. Varsayılan mesaj "Çıkış oluşturuluyor"dur (veya buna benzer bir ifadedir) ancak daha ayrıntılı bir mesaj da sağlayabilirsiniz. Derleme aracının bu tür ilerleme mesajlarının yazdırılıp yazdırılmayacağını kontrol etmesine olanak tanıdığı için cmd komutunuzda echo veya diğer yazdırma ifadeleri yerine bu özelliği kullanın.
output_licenses	Licence type; optional common attributes adresine göz atın.
output_to_bindir	Boolean; optional; nonconfigurable; default is False Bu seçenek True olarak ayarlanırsa çıkış dosyalarının genfiles dizini yerine bin dizine yazılmasına neden olur.
tools	List of labels; optional Bu kuralın araç bağımlılıkları listesi. Daha fazla bilgi için bağımlılıkların tanımına bakın. Derleme sistemi, genrule komutu çalıştırılmadan önce bu ön koşulların derlendiğinden emin olur. Bu araçlar derlemenin bir parçası olarak yürütüldüğü için ana makine yapılandırması kullanılarak derlenirler. 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şturulduklarından emin olmak için srcs yerine 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, kullanıcılar için "yararlı" kabul edilen bir dizi testi tanımlar. Bu sayede projeler "check-in yapmadan önce çalıştırmanız gereken testler", "projemizin stres testleri" veya "tüm küçük testler" gibi test grupları tanımlayabilir. blaze test komutu bu tür bir 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 (buna "test_suite genişletmesi" denir) listeler, ardından 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 test paketi:

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

Mevcut paketteki tüm testleri çalıştıracak, kararlı olmayan 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", "Veritabanı" veya "-geçersiz" 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" içeren bir paket 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 karakter, etiketin metninin bir parçası olarak değerlendirilmez. Bu, olumlu ve olumsuz ayrımın daha kolay okunmasını sağlar. Yalnızca pozitif etiketlerin tümüyle ve negatif etiketlerin hiçbiriyle eşleşmeyen test kuralları test grubuna dahil edilir. Bunun, filtrelenen testlere ait bağımlılıklarda hata kontrolünün atlandığı anlamına gelmediğini unutmayın.Atlanan testlere ait bağımlılıkların yine de yasal olması gerekir (ör. görünürlük kısıtlamaları tarafından engellenmemiş olmalıdır). manual etiket anahtar kelimesi, joker karakter hedef kalıpları içeren çağrılarda blaze test komutu tarafından gerçekleştirilen "test_suite expansion" tarafından yukarıdakinden farklı şekilde ele alınır. Burada, "manuel" olarak etiketlenen test_suite hedefleri filtrelenir (ve dolayısıyla genişletilmez). Bu davranış, blaze build ve blaze test'un genel olarak joker karakter hedef kalıplarını ele alma şekliyle tutarlıdır. manual etiketinden bağımsız olarak paketler her zaman tests sorgu işlevi tarafından genişletildiğinden, bunun blaze query 'tests(E)''ün davranışından açıkça farklı olduğunu unutmayın. Bir testin size değerinin, filtreleme amacıyla etiket olarak kabul edildiğini unutmayın. Birbirine hariç tutulan etiketlere sahip testleri (ör. tüm küçük ve orta testler) içeren bir test_suite'ye ihtiyacınız varsa üç test_suite kuralı oluşturmanız gerekir: biri tüm küçük testler için, biri tüm orta testler için ve biri de önceki ikisini içeren.
tests	List of labels; optional; nonconfigurable Herhangi bir dilin test paketlerinin ve test hedeflerinin listesi. Dilden bağımsız olarak tüm *_test kabul edilir. Ancak, test çalıştırmış olsalar bile *_binary hedefleri kabul edilmez. Belirtilen tags'e göre filtreleme yalnızca doğrudan bu özellikte listelenen testler için yapılır. Bu özellik test_suite içeriyorsa bu test_suite'ler içindeki testler bu test_suite tarafından filtrelenmez (zaten filtrelenmiş kabul edilir). tests özelliği belirtilmezse veya boşsa kural, varsayılan olarak geçerli BUILD dosyasında manual olarak etiketlenmemiş tüm test kurallarını içerir. Bu kurallar tag filtrelemesine tabi olmaya devam eder.