Genel Kurallar

Sorun bildir Kaynağı görüntüle Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Kurallar

takma ad

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

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

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

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

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

  • Komut satırında takma 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

Ad; zorunlu

Bu hedef için benzersiz bir ad.

actual

Etiket; zorunlu

Bu takma adın atıfta bulunduğu hedef. Kural olması gerekmez, giriş dosyası da olabilir.

config_setting

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

Yapılandırılabilir ö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ın nasıl kullanılacağı ile ilgili bilgi için select (Seçme) bölümüne ve genel özelliğe genel bakış için Yapılandırılabilir özellikler bölümüne bakın.

Örnekler

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

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

Aşağıdaki 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) şunları yapar: -ios_multi_cpus=a,b ve ios_multi_cpus=a --ios_multi_cpus=b ikisi de ["a", "b"] oluşturur. 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, daha zayıf bir 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 pakette tanımlanan ortak bir config_setting öğesine başvurun.
  • values, define_values ve constraint_values aynı config_setting içinde herhangi bir kombinasyonda kullanılabilir ancak belirli bir config_setting için en az biri ayarlanmalıdır.

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

constraint_values

Etiketler listesi; yapılandırılamaz; varsayılan değer []

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 belirlediği ek kısıtlama değerleri yoksayılır. Ayrıntılar için Yapılandırılabilir Derleme Özellikleri bölümüne bakın.

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

define_values

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

values ile aynı 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

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

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

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

values

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

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

Bu kural, select ifadesinde kendisine referans veren yapılandırılmış hedefin yapılandırmasını devralır. Sözlükteki her giriş için yapılandırması 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ırmayla oluşturulabilmesidir. Örneğin, bir yürütme yapılandırmasının "cpu" özelliği --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.

Bir işaret, komut satırında açıkça ayarlanmazsa varsayılan değeri kullanılır. Bir anahtar sözlükte birden çok kez görünüyorsa yalnızca son ö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 meydana gelir.

dosya grubu

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

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

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

Ad; zorunlu

Bu hedef için benzersiz bir ad.

srcs

Etiketler listesi; varsayılan değer []'dir.

Dosya grubunun üyeleri olan hedeflerin listesi.

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

data

Etiketler listesi; varsayılan değer []'dir.

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

data özelliğinde adlandırılan 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, runfiles özelliği bağlı kuralın runfiles öğesine eklenir. Veri dosyalarına bağımlı olma ve veri dosyalarını 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

Dize; varsayılan değer ""

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ını içeren bir kategoridir.

Genquery

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

genquery(), Blaze sorgu dilinde belirtilen bir sorguyu çalıştırır ve sonucu bir dosyaya 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ışı, --output=graph|minrank|maxrank hariç olmak üzere veya üst düzey işlev olarak somepath kullanıldığında, belirlenebilir çıkışı zorunlu kılmak için alfabetik olarak sıralanır.

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

Örnekler

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

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

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

compressed_output

Boole; varsayılan değer False'tir

True ise sorgu çıkışı GZIP dosya biçiminde yazılır. Bu ayar, sorgu çıkışının büyük olması beklendiğinde Bazel'in bellek kullanımındaki ani artışları önlemek için kullanılabilir. Bazel, bu ayarın değerinden bağımsız olarak 220 bayttan büyük sorgu çıkışlarını zaten dahili olarak sıkıştırır. Bu nedenle, bu ayarı True olarak ayarlamak, tutulan yığının boyutunu azaltmayabilir. Ancak bu, Bazel'in çıkış dosyasını yazarken sıkıştırma işlemini atlamasına olanak tanır. Bu işlem, hafıza açısından yoğun olabilir.
expression

Dize; zorunlu

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

Dize listesi; varsayılan değer []'tir.

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

Etiketler listesi; zorunlu

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

Boole; varsayılan değer True'tir

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

genrule

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

genrule, kullanıcı tanımlı 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.

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

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 yürütme mimarisinde (ikisi farklı olabilir) yürütülür. Genel amaçlı bir test kuralına ihtiyacınız varsa sh_test kullanın.

Çapraz derlemede dikkat edilmesi gereken noktalar

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

Genrule'lar derleme sırasında çalışırken bunların çıkışları genellikle derleme sonrasında 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 kodun, derleme için kullanılan CPU'da çalışamayacağı açık bir şekilde vardır. Ancak, C derleyicisinin (kaynaktan derlenmişse) kendisinin çalışması gerekir.

Derleme sistemi, derlemenin çalıştırıldığı makineleri tanımlamak için exec 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, gerekirse hedef yapılandırması için derlenir, tools ise exec 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

Yürütme-yürütme derlemesi: Bazı durumlarda, derleme sisteminin genrules'i, çıkışın derleme sırasında da yürütülebilmesi için ç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 exec yapılandırması için çıkışını üretmesi gerekir. Bu durumda, derleme sistemi otomatik olarak doğru işlemi yapar: Hedef yapılandırma yerine yürütme yapılandırması için ilk genrule'nin 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 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 başarısız olacak şekilde yapılandırılan Bash kabuğu tarafından set -e -o pipefail kullanılarak yürütülür.

Derleme aracı; Bash komutunu yalnızca PATH, PWD, TMPDIR ve birkaç diğer temel değişkenleri tanımlayan temiz bir işlem ortamında yürütür. Derlemelerin 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, şu anda zorunlu olmasa da komutun alt öğeleri olan işlemleri bağlamak dışında ağa erişmemelidir.

Derleme sistemi, mevcut çıkış dosyalarını otomatik olarak siler ancak genrule çalıştırmadan önce gerekli üst dizinleri oluşturur. Ayrıca, başarısız bir işlem 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ırmalara göre ayrılması nedeniyle, genruller sabit kodlu ve/veya mutlak yollara dayanamaz.
  • 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 faydalı olsa da bu, kolayca gürültüye dönüşebilir. Başarılı bir oluşturucu sessiz olmalıdır. Diğer yandan, başarısız bir genel kural iyi hata mesajları vermelidir.
  • $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
  • Simge bağlantıları ve dizinler 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 genel kurala referans verirken genel kuralın etiketini veya ayrı 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 oluşturur. Komut giriş almadığı için kaynak yok. 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

Ad; zorunlu

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

Etiketler listesi; varsayılan değer []'dir.

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

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şullara ilişkin dosyaların adları, $(SRCS) içinde boşlukla ayrılmış bir liste olarak komut tarafından kullanılabilir. Alternatif olarak, bağımsız bir srcs hedefinin //x:y yolu, $(location //x:y) kullanılarak veya srcs içindeki tek giriş olması koşuluyla $< kullanılarak elde edilebilir.

outs

Dosya adları listesi; yapılamayan; gerekli

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

Çıkış dosyaları paket sınırlarını aşmamalıdır. Çıkış dosyası 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 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

Dize; varsayılan değer ""'tir

Çalıştırılacak komut. $(location) ve "Make" değişkeni yerine koyma işlemine tabidir.
  1. İlk olarak $(location) ikame uygulanır. Bu işlemde $(location label) ve $(locations label)'in (ve execpath, execpaths, rootpath ve rootpaths ile ilgili değişkenleri kullanan benzer yapıların) tüm oluşumları değiştirilir.
  2. Ardından, "Make" değişkenleri genişletilir. Önceden tanımlanmış $(JAVA), $(JAVAC) ve $(JAVABASE) değişkenlerinin exec 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.
  3. Son olarak, oluşturulan komut Bash kabuğu kullanılarak yürütülür. Çıkış kodu sıfır değilse komutun başarısız olduğu kabul edilir.
Bu, 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

Dize; varsayılan değer ""

Ç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

Dize; varsayılan değer ""

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 kümesini etkinleştir.
    • /V:ON - gecikmeli değişken genişletmeyi etkinleştirme
    • /D - AutoRun kayıt defteri girişlerini yoksayın.
  • $(location) ve "Make" değişkeninin değiştirilmesinden sonra, yollar, Windows stil yollarına (ters eğik çizgiyle) genişletilir.
cmd_ps

Dize; varsayılan değer ""'tir

Windows&#39;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ı kolaylaştırmak ve hataya daha az açık olmasını sağlamak için genel modda Powershell komutunu yürütmeden önce ortamı ayarlamak amacıyla 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 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.
executable

Boole; yapılandırılamaz; varsayılan değer False'dir.

Çıkışı yürütülebilir olarak tanımlayın.

Bu işaretin Doğru değerine ayarlanması, çıktının yürütülebilir bir dosya olduğu ve run komutu kullanılarak çalıştırılabileceği anlamına gelir. Bu durumda genrule tam olarak bir çıkış 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 edilmesi desteklenmez.

local

Boole; varsayılan değer False'tir

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 "yerel" değerinin sağlanmasına eşdeğerdir (tags=["local"]).

message

Dize; varsayılan değer ""'tir

İlerleme mesajı.

Bu derleme adımı yürütülürken yazdırılacak bir ilerleme mesajı. Varsayılan olarak "Çıkış oluşturma" mesajı (ya da eşit derecede uygunsuz bir mesaj) olur ancak daha spesifik bir mesaj sağlayabilirsiniz. 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

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

common attributes adresine göz atın.
output_to_bindir

Boole; yapılandırılamaz; varsayılan değer False'dir.

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

tools

Etiketler listesi; varsayılan değer []'dir.

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 exec yapılandırması kullanılarak derlenirler. 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.

starlark_doc_extract

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

starlark_doc_extract(), belirli bir .bzl veya .scl dosyasında tanımlanan ya da yeniden dışa aktarılan kurallar, işlevler (makrolar dahil), görünümler ve sağlayıcılarla ilgili dokümanları ayıklayıp çıkarır. Bu kuralın çıktısı, Bazel kaynak ağacındaki stardoc_output.proto dosyasında tanımlandığı şekilde bir ModuleInfo ikili protodur.

Dolaylı çıkış hedefleri

  • name.binaryproto (varsayılan çıkış): ModuleInfo ikili programı.
  • name.textproto (yalnızca açıkça istenirse derlenir): name.binaryproto'un metin proto sürümü.

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

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

deps

Etiketler listesi; varsayılan değer []'dir.

src tarafından load() edilen Starlark dosyalarını sarmalayan hedeflerin listesi. Bu hedefler normal kullanımda bzl_library hedefleri olmalıdır ancak starlark_doc_extract kuralı bunu zorunlu tutmaz ve DefaultInfo bölümünde Starlark dosyaları sağlayan tüm hedefleri kabul eder.

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

src

Etiket; zorunlu

Dokümanların ayıklanacağı Starlark dosyası.

Bunun kaynak ağacındaki bir dosya olması gerektiğini unutmayın. Bazel, load() tarafından oluşturulan dosyaları kullanamaz.

render_main_repo_name

Boole; varsayılan değer False'tir

Doğru ise ana depoda etiketleri, repo bileşeniyle birlikte yayınlanan dokümanda oluştur (yani //foo:bar.bzl, @main_repo_name//foo:bar.bzl olarak yayınlanır).

Ana depo için kullanılacak ad, ana deponun MODULE.bazel dosyasında (Bzlmod etkinse) module(name = ...) veya ana deponun WORKSPACE dosyasında workspace(name = ...) bölümünden alınır.

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

symbol_names

Dize listesi; varsayılan değer []'tir.

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

starlark_doc_extract, yalnızca aşağıdaki durumlarda bir öğe için doküman yayınlar:

  1. Öğenin tam nitelikli adının her bir bileşeni herkese açık olmalıdır (yani, tam nitelikli ad bileşenlerinin her birinin ilk karakteri "_" değil, alfabedeki bir harf olmalıdır); ve
    1. Ya symbol_names listesi boştur (varsayılan durumdur) veya
    2. varlığın tam nitelikli adı veya varlığın iç içe yerleştirildiği bir yapının tam nitelikli adı symbol_names listesindedir.

test_suite

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

test_suite, kullanıcılar için "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 şu organizasyona uyar: blaze test //some/test:suite gibi bir çağrı için Blaze önce //some/test:suite hedefi tarafından geçişli olarak dahil edilen tüm test hedeflerini numaralandırır (buna "test_suite genişletmesi" denir), ardından Blaze bu hedefleri oluşturup test eder.

Örnekler

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

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

Belirli bir test grubunu çalıştıran 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

Ad; zorunlu

Bu hedef için benzersiz bir ad.

tags

Dize listesi; yapılandırılamaz; varsayılan değer []

"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" paket etiketi 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 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 hedefleri filtrelenir (ve dolayısıyla genişletilmez). Bu davranış, blaze build ve blaze test öğelerinin genel olarak joker karakter hedef kalıplarını işleme şekliyle tutarlıdır. 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

Etiketler listesi; yapılandırılamaz; varsayılan değer []

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.