Genel Kurallar

Sorun bildir Kaynağı görüntüle Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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ı, bir kuralın adlandırılacağı başka bir ad oluşturur.

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

Hedefin yeniden adlandırılması için birçok dosyada değişiklik yapılması gereken büyük depolarda diğer adlandırma yararlı olabilir. Ayrıca, bu mantığı birden fazla hedef için yeniden kullanmak istiyorsanız select işlev çağrısını depolamak için alias kuralını da kullanabilirsiniz.

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 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:

  • Takma adları komut satırında belirtilen testler çalıştırılmaz. Referans verilen testi çalıştıran bir takma ad tanımlamak için test_suite kuralını tests özelliğinde tek bir hedefle kullanın.
  • Ortam grupları tanımlarken environment kurallarının diğer 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 işaret ettiği hedef. Kural olması gerekmez, giriş dosyası da olabilir.

config_setting

Kural kaynağını görüntüleme
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ğı hakkında bilgi edinmek için select, genel özelliklere genel bakış için Yapılandırılabilir özellikler başlıklı makaleyi inceleyin.

Örnekler

Aşağıdaki, --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 tanımlamayı uygulayan tüm derlemelerle eşleşir FOO=bar (örneğin, bazel build --cpu=arm --define FOO=bar ...):

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

Aşağıdaki, user-defined flag'i ayarlayan tüm derlemelerle eşleşir --//custom_flags:foo=1 (komut satırında açıkça veya .bazelrc dosyalarından örtülü olarak):

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

Aşağıdaki, x86_64 mimarisine ve glibc sürüm 2.25'e sahip bir platformu hedefleyen tüm derlemelerle eşleşir. Bu eşleşme, //example:glibc_2_25 etiketli bir constraint_value öğesinin var olduğu varsayılarak yapılır. Bir platform, bu ikisinin ötesinde ek kısıtlama değerleri tanımlasa bile eşleşmeye devam eder.

  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şmesi mümkündür. Örneğin, bir hedefin bağımlı olduğu platformdan farklı bir platform için oluşturulması gerekebilir. Bu, bir config_setting üst düzey komut satırı işaretleriyle eşleşmese bile bazı derleme hedefleriyle eşleşebileceği anlamına gelir.

Notlar

  • Birden fazla config_setting mevcut yapılandırma durumuyla eşleştiğinde ne olacağını öğrenmek için select (seç) bölümüne bakın.
  • Kısa biçimleri destekleyen işaretler (ör. --compilation_mode ve -c) için values tanımları tam biçimde olmalıdır. Bunlar, her iki form kullanılarak yapılan çağırmalarla otomatik olarak eşleşir.
  • Bir işaret birden fazla değer alıyorsa (ör. --copt=-Da --copt=-Db veya liste türünde bir Starlark işareti), "a" gerçek listede herhangi bir yerde bulunuyorsa values = { "flag": "a" } eşleşir.

    values = { "myflag": "a,b" } aynı şekilde çalışır: Bu, --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b ve --myflag=c,b,a ile eşleşir. Tam anlamlar işaretler arasında farklılık gösterir. Örneğin, --copt aynı örnekte birden çok değeri desteklemez: --copt=a,b ["a,b"] değerini, --copt=a --copt=b ise ["a", "b"] değerini üretir (bu nedenle values = { "copt": "a,b" }, ikincisiyle değil, ilkiyle eşleşir). Ancak --ios_multi_cpus (Apple kuralları için) yapılır: -ios_multi_cpus=a,b ve ios_multi_cpus=a --ios_multi_cpus=b ifadelerinin her ikisi de ["a", "b"] sonucunu verir. İşaret tanımlarını kontrol edin ve koşullarınızı dikkatlice test ederek beklentilerinizi karşıladığını doğrulayın.

  • Yerleşik derleme işaretleriyle modellenmeyen koşullar tanımlamanız gerekiyorsa Starlark ile tanımlanan işaretleri kullanın. --define karakterini de kullanabilirsiniz ancak bu karakter daha zayıf 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 öğesine referans verin.
  • values, define_values ve constraint_values aynı config_setting içinde herhangi bir kombinasyonla kullanılabilir ancak herhangi bir config_setting için en az birinin ayarlanması gerekir.

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

constraint_values

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

Hedef platformun bu config_setting ile eşleşmek için belirtmesi gereken minimum constraint_values kümesi. (Yürütme platformu burada dikkate alınmaz.) Platformun sahip olduğu diğer tüm 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'nın aynı select'da eşleşmesi durumunda, bu özellik config_setting'lardan birinin diğerinin uzmanlık alanı olup olmadığını belirlemek için dikkate alınmaz. Diğer bir deyişle, bir config_setting başka bir platformla daha güçlü bir şekilde eşleşemez.

define_values

Sözlük: Dize -> Dize; nonconfigurable; varsayılan değer {}

values ile aynıdır ancak özellikle --define işareti için kullanılır.

--define, söz dizimi (--define KEY=VAL) nedeniyle özeldir. Bu söz dizimi, KEY=VAL'nin Bazel işareti 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",
                })
          

aynı anahtar (define) sözlükte iki kez göründüğü için çalışmaz. Bu özellik, söz konusu sorunu çözer:

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

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

--define, normal işaret söz dizimiyle 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; nonconfigurable; varsayılan değer {}

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

Kullanıcı tanımlı işaretler etiket olarak, yerleşik işaretler ise rastgele dizeler olarak referans verildiğinden bu ayrı bir özelliktir.

values

Sözlük: Dize -> Dize; nonconfigurable; varsayılan değer {}

Bu kurala uyan yapılandırma değerleri grubu (derleme işaretleri olarak ifade edilir)

Bu kural, kendisini bir select ifadesinde referans alan 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şiyorsa Bazel çağrısının "eşleştiği" kabul edilir. Örneğin, values = {"compilation_mode": "opt"}, hedef yapılandırılmış kurallarda bazel build --compilation_mode=opt ... ve bazel build -c opt ... çağırmalarıyla eşleşir.

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

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

filegroup

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

Bir hedef koleksiyonuna uygun bir ad vermek için filegroup simgesini kullanın. Bunlar daha sonra diğer kurallardan referans alınabilir.

Dizinlere doğrudan referans vermek yerine filegroup kullanılması önerilir. Derleme sistemi, dizinin altındaki tüm dosyalar hakkında tam bilgiye sahip olmadığından bu dosyalar değiştiğinde yeniden derleme yapmayabilir. Bu nedenle, ikinci yöntem güvenilir değildir. glob ile birlikte kullanıldığında filegroup, tüm dosyaların derleme sistemi tarafından açıkça bilinmesini sağlayabilir.

Örnekler

İki kaynak dosyasından oluşan bir filegroup oluşturmak için

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

Alternatif olarak, bir testdata dizinini taramak 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 alınan bir etiketle filegroup öğesine 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

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

Dosya grubunun üyesi olan hedeflerin listesi.

srcs özelliğinin değeri için glob ifadesinin sonucunu kullanmak yaygındır.

data

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

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

data özelliğinde belirtilen hedefler, bu filegroup kuralının runfiles bölümüne eklenir. filegroup, başka bir kuralın data özelliğinde referans olarak kullanıldığında runfiles, bağımlı kuralın runfiles özelliğine eklenir. Veri dosyalarına nasıl bağlı kalacağınız ve bunları 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 dokümanları inceleyin.

output_group

Dize; varsayılan değer ""

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

"Çıkış grubu", bir hedefin çıkış yapıtlarının kategorisidir ve bu kuralın uygulamasında belirtilir.

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çişli kapanımını ziyaret etmesine izin verilir. Bu kuralı ihlal eden sorgular, yürütme sırasında başarısız olur. Bunun nedeni, strict değerinin belirtilmemiş olması veya doğru olmasıdır (strict değeri yanlışsa kapsam dışı hedefler uyarı verilerek 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 spesifikasyonları (ör. //pkg:* veya //pkg:all) içeren sorgulara burada izin verilmemesidir. Bunun iki nedeni vardır: Birincisi, genquery, sorgunun geçişli kapanışının dışındaki hedeflerin çıkışını etkilemesini önlemek için bir kapsam belirtmelidir.İkincisi ise BUILD dosyaları, joker karakter bağımlılıklarını desteklemez (ör. deps=["//a/..."] izin verilmez).

--output=graph|minrank|maxrank veya somepath üst düzey işlev olarak kullanıldığında hariç olmak üzere, deterministik çıkışı zorunlu kılmak için genquery'nin çıkışı sözlükbilimsel olarak sıralanır.

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

Örnekler

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

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

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

compressed_output

Boole değeri; varsayılan değer False'dır.

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ında 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ı dahili olarak sıkıştırdığından bu ayarı True olarak ayarlamak saklanan yığını azaltmayabilir. Ancak bu, Bazel'in çıkış dosyasını yazarken sıkıştırmayı açmayı atlamasına olanak tanır. Bu işlem, yoğun bellek kullanımı gerektirebilir.
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 dizinine göre çözümlenir. Örneğin, a/BUILD dosyasındaki bu özellikteki :b etiketi, //:b hedefini ifade eder.
opts

Dizelerin listesi; varsayılan değer []'dır.

Sorgu motoruna iletilen seçenekler. Bunlar, bazel query'ya iletilebilen komut satırı seçeneklerine karşılık gelir. Bazı sorgu seçeneklerine burada 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ğerlere sahip olur.
scope

Etiket listesi; zorunlu

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

Boole değeri; varsayılan değer True'dır.

Doğruysa sorguları kapsamlarının geçişli kapanışından kaçan hedefler oluşturulamaz. Yanlışsa Bazel, sorgunun geri kalanını tamamlarken bir uyarı yazdırır ve sorgu yolunun kapsam dışına çıkmasına neden olan kısmı atlar.

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 mevcut cc_* kurallarına uymanız gerekir. Çünkü tüm ağır işler sizin için zaten yapılmıştır.

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

Testleri çalıştırmak için genrule kullanmayın. Önbelleğe alma politikaları ve ortam değişkenleri de dahil olmak üzere testler ve test sonuçları için özel muafiyetler vardır. Testlerin genellikle derleme tamamlandıktan sonra ve hedef mimaride çalıştırılması gerekirken genrule'lar 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 kuralını kullanın.

Çapraz Derlemeyle İlgili Dikkat Edilmesi Gerekenler

Ç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. Mikrodenetleyici için C kodu derleme örneğini ele alalım: Derleyici, C kaynak dosyalarını kabul eder ve mikrodenetleyicide çalışan kod oluşturur. Oluşturulan kod, derlenmesinde kullanılan CPU'da çalışamaz ancak C derleyicinin (kaynaktan derlendiyse) çalışması gerekir.

Derleme sistemi, derlemenin üzerinde çalıştığı makineleri tanımlamak için exec yapılandırmasını, derlemenin çıktısının üzerinde çalışması gereken makineleri tanımlamak için ise hedef yapılandırmayı kullanır. Bu seçeneklerin her birini yapılandırma imkanı 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 oluşturulmasını sağlar: srcs target yapılandırması için (gerekirse) oluşturulur, tools exec yapılandırması için oluşturulur ve çıkışın target 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'da deps özelliği tanımlanmaması kasıtlıdır: 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 genrule'larda bu düzeyde bir otomasyon mümkün değildir. Genrules yalnızca dosya ve runfiles düzeyinde çalışır.

Özel Durumlar

Exec-exec derlemesi: Bazı durumlarda, derleme sisteminin genrules'u, çıkışın derleme sırasında da yürütülebileceği şekilde çalıştırması gerekir. Örneğin, bir genrule daha sonra başka bir genrule tarafından kullanılan özel bir derleyici oluşturuyorsa, ilk genrule çıkışını exec yapılandırması için üretmelidir. Çünkü derleyici, diğer genrule'da bu yapılandırmada çalışır. Bu durumda, derleme sistemi doğru şeyi otomatik olarak yapar: hedef yapılandırma yerine yürütme yapılandırması için ilk genrule'un 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 işlem hattı başarısız olduğunda başarısız olacak şekilde yapılandırılmış bir Bash kabuğu tarafından set -e -o pipefail kullanılarak yürütülür.

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

Bir genrule komutu, şu anda zorunlu kılınmamış olsa da, komutun alt işlemleri olan süreçlere bağlanmak dışında ağa erişmemelidir.

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

Genel Tavsiye

  • 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 sabit 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'in, oluşturulacağını düşündüğünüz bir genrule'u yeniden oluşturmaması) ve önbellek performansının düşmesine neden olur.
  • Çıkışlar, araçlar ve kaynaklar için $(location)'ı yoğun bir şekilde kullanın. Farklı yapılandırmalar için çıkış dosyalarının ayrılması nedeniyle, genrules sabit kodlanmış ve/veya mutlak yollara dayanamaz.
  • Aynı veya çok benzer genrule'lar birden fazla yerde kullanılıyorsa ortak bir Starlark makrosu yazın. Genrule karmaşıksa bunu bir komut dosyasında veya Starlark kuralı olarak uygulamayı düşünebilirsiniz. Bu, okunabilirliğin yanı sıra test edilebilirliği de artırır.
  • Çıkış kodunun, genrule'un başarılı veya başarısız olduğunu doğru şekilde gösterdiğinden emin olun.
  • stdout veya stderr'ye bilgilendirici mesajlar yazmayın. Bu, hata ayıklama için yararlı olsa da kolayca gürültüye dönüşebilir. Başarılı bir genrule sessiz olmalıdır. Öte yandan, başarısız olan 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).
  • Sembolik bağlantılar ve dizinler oluşturmaktan kaçının. Bazel, genrules tarafından oluşturulan dizin/sembolik bağlantı yapısını kopyalamaz ve dizinlerin bağımlılık kontrolü güvenilir değildir.
  • Diğer kurallarda genrule'a referans verirken genrule'un etiketini veya tek tek çıkış dosyalarının etiketlerini kullanabilirsiniz. Bazen bir yaklaşım daha okunabilir olur, bazen de diğeri: Tüketici kuralının srcs bölümünde çıkışlara adlarıyla referans vermek, genrule'un diğer çıkışlarının yanlışlıkla alınmasını önler ancak genrule çok sayıda çıkış üretiyorsa bu işlem sıkıcı olabilir.

Örnekler

Bu örnek foo.h oluşturur. Komut herhangi bir giriş almadığından kaynak yoktur. Komut tarafından çalıştırılan "binary", genrule ile aynı paketteki bir Perl komut dosyasıdır.

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

Aşağıdaki örnekte, filegroup ve başka bir genrule'nin çıkışlarının nasıl kullanılacağı gösterilmektedir. Açık $(location) yönergeleri yerine $(SRCS) kullanmanın da işe yarayacağını unutmayın. Bu örnekte, gösterim amacıyla ikincisi 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ünde adıyla atıfta bulunabilirsiniz. Kural kaynak dosyalar oluşturuyorsa srcs özelliğini kullanmanız gerekir.
srcs

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

Bu kural için girişlerin listesi (ör. işlenecek kaynak dosyalar).

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

Derleme sistemi, bu ön koşulların genrule komutu çalıştırılmadan önce oluşturulmasını sağlar. Bu ön koşullar, orijinal derleme isteğiyle aynı yapılandırma kullanılarak oluşturulur. Bu ön koşulların dosyalarının adları, komuta $(SRCS) içinde boşlukla ayrılmış bir liste olarak sağlanır. Alternatif olarak, srcs hedefinin yolu $(location //x:y) veya srcs'daki tek giriş olması koşuluyla $< kullanılarak elde edilebilir.//x:y

outs

Dosya adlarının listesi; yapılandırılamaz; zorunlu

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 kurala özel "Marka" değişkenleri ($@, $(OUTS), $(@D) veya $(RULEDIR)) ya da $(location) yerine koyma kullanılarak kullanılabilir.

cmd

Dize; varsayılan değer ""

Çalıştırılacak komut. $(location) ve "Marka" değişkeni yerine koyma işlemine tabidir.
  1. Önce $(location) yerine koyma işlemi uygulanır. Bu işlemde $(location label) ve $(locations label) (ve ilgili değişkenler execpath, execpaths, rootpath ve rootpaths kullanılarak oluşturulan benzer yapılar) tüm oluşumları değiştirilir.
  2. Ardından, "Marka" değişkenleri genişletilir. $(JAVA), $(JAVAC) ve $(JAVABASE) önceden tanımlanmış değişkenlerinin exec yapılandırması altında genişlediğini unutmayın. Bu nedenle, derleme adımının bir parçası olarak çalışan Java çağırmaları, paylaşılan kitaplıkları ve diğer bağımlılıkları doğru şekilde yükleyebilir.
  3. Son olarak, ortaya çıkan 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 için yedek seçenektir. Bu seçeneklerden hiçbiri geçerli değilse kullanılır.

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

cmd_bash

Dize; varsayılan değer ""

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

Bu özellik, cmd özelliğinden daha yüksek önceliğe sahiptir. 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 iş komutu.

Bu özellik, cmd ve cmd_bash özelliklerinden daha yüksek önceliğe sahiptir. Komut, cmd özelliğiyle benzer şekilde çalışır ancak aşağıdaki farklılıklar vardır:

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

Dize; varsayılan değer ""

Windows'ta çalıştırılacak Powershell komutu.

Bu özellik, cmd, cmd_bash ve cmd_bat özelliklerinden daha yüksek önceliğe sahiptir. Komut, aşağıdaki farklılıklar dışında cmd özelliğiyle benzer şekilde çalışır:

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

Powershell'in daha kolay kullanılabilmesi ve daha az hata içermesi 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 - İmzalanmamış komut dosyalarının çalıştırılmasına izin verilir.
  • $errorActionPreference='Stop' - ; ile ayrılmış birden fazla komut varsa bir PowerShell CmdLet'i başarısız olduğunda işlem hemen sonlandırılır ancak bu, harici komut için GEÇERLİ DEĞİLDİR.
  • $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

Çıkışın yürütülebilir olduğunu beyan edin.

Bu işareti True olarak ayarlamak, çı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 çıkış üretmelidir. Bu özellik ayarlanırsa run, içeriğine bakılmaksızın dosyayı yürütmeye çalışır.

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

local

Boole değeri; varsayılan değer False'dır.

Doğru olarak ayarlanırsa bu seçenek, genrule öğesinin "yerel" stratejisi kullanılarak çalıştırılmasını zorlar. Bu durumda uzaktan yürütme, korumalı alan ve kalıcı çalışanlar olmaz.

Bu, etiket olarak "local" (tags=["local"]) sağlamaya eş değerdir.

message

Dize; varsayılan değer ""

İlerleme mesajı

Bu derleme adımı yürütülürken yazdırılacak bir ilerleme mesajı. Varsayılan olarak, mesaj "Çıkış oluşturuluyor" (veya benzer şekilde sıkıcı bir mesaj) şeklindedir ancak daha spesifik bir mesaj sağlayabilirsiniz. Bu özelliği, echo komutunuzdaki cmd veya diğer yazdırma ifadeleri yerine kullanın. Bu sayede, derleme aracının bu tür ilerleme mesajlarının yazdırılıp yazdırılmayacağını kontrol etmesine olanak tanırsınız.

output_licenses

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

common attributes sayfasına göz atın.
output_to_bindir

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

True olarak ayarlanırsa bu seçenek, çıkış dosyalarının genfiles dizini yerine bin dizinine yazılmasına neden olur.

tools

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

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

Derleme sistemi, genrule komutu çalıştırılmadan önce bu ön koşulların karşılanmasını sağlar. Bu araçlar derlemenin bir parçası olarak yürütüldüğünden, exec yapılandırması kullanılarak oluşturulur. Tek bir tools hedef //x:y yolu, $(location //x:y) kullanılarak elde edilebilir.

*_binary veya cmd tarafından yürütülecek herhangi bir araç, doğru yapılandırmada oluşturulduklarından emin olmak için srcs'de değil, 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), yönler ve sağlayıcılarla ilgili dokümanları ayıklar. Bu kuralın çıktısı, Bazel kaynak ağacındaki stardoc_output.proto içinde tanımlanan bir ModuleInfo ikili proto'dur.

Örtülü çıkış hedefleri

  • name.binaryproto (varsayılan çıkış): A ModuleInfo ikili proto.
  • name.textproto (yalnızca açıkça istenirse oluşturulur): name.binaryproto uygulamasının metin proto sürümü.

Uyarı: Bu kuralın çıkış biçiminin sabit olacağı garanti edilmez. Bu doküman, esas olarak Stardoc'un şirket içi kullanımı için hazırlanmıştır.

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

deps

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

load()-ed by src ile sarmalanan Starlark dosyalarını içeren hedefler listesi. Bu hedefler normal kullanımda bzl_library hedefleri olmalıdır ancak starlark_doc_extract kuralı bunu zorunlu kılmaz ve DefaultInfo içinde Starlark dosyaları sağlayan tüm hedefleri kabul eder.

Sarmalanmış Starlark dosyalarının kaynak ağacındaki dosyalar olması gerektiğini unutmayın. Bazel, load() oluşturamaz.

src

Etiket: zorunlu

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

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

render_main_repo_name

Boole değeri; varsayılan değer False'dır.

Doğruysa, ana depodaki oluşturma etiketleri, depo bileşeniyle birlikte yayınlanan dokümanlarda oluşturulur (diğer bir deyişle, //foo:bar.bzl, @main_repo_name//foo:bar.bzl olarak yayınlanır).

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

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

symbol_names

Dizelerin listesi; varsayılan değer []'dır.

Dışa aktarılan işlevlerin, kuralların, sağlayıcıların veya yönlerin (ya da iç içe yerleştirildikleri yapılar) nitelikli adlarının, dokümanların çıkarılacağı isteğe bağlı bir listesi. Burada tam ad, bir öğenin modülün kullanıcısına sunulduğu ad anlamına gelir. Bu ada, ad alanı oluşturma amacıyla öğenin içine yerleştirildiği tüm yapılar da dahildir.

starlark_doc_extract, yalnızca aşağıdaki durumlarda bir öğeyle ilgili doküman yayınlar:

  1. öğenin tam adının her bileşeni herkese açık olmalıdır (diğer bir deyişle, tam adın her bileşeninin ilk karakteri alfabetik olmalı, "_" olmamalıdır); ve
    1. symbol_names listesi boşsa (varsayılan durum) veya
    2. Varlığın tam adı veya varlığın iç içe yerleştirildiği bir yapının tam adı symbol_names listesinde yer alıyorsa.

test_suite

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

test_suite, insanlar için "faydalı" olarak kabul edilen bir dizi testi tanımlar. Bu sayede projeler, "check-in işleminden önce çalıştırmanız gereken testler", "projemizin yük testleri" veya "tüm küçük testler" gibi test kümeleri tanımlayabilir. blaze test komutu bu tür bir sıralamaya uyar: blaze test //some/test:suite gibi bir çağırma işleminde 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şletme" diyoruz), ardından Blaze bu hedefleri oluşturur ve test eder.

Örnekler

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

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

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

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

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

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

Bağımsız değişkenler

Özellikler
name

Ad; zorunlu

Bu hedef için benzersiz bir ad.

tags

Dizelerin listesi; yapılandırılamaz; varsayılan değer []'dır.

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

"-" karakteriyle başlayan etiketler negatif etiket olarak kabul edilir. Önündeki "-" karakteri etiketin bir parçası olarak kabul edilmez. Bu nedenle, "-small" boyutundaki bir 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 net hale getirmek için etiketler "+" karakteriyle de başlayabilir. Bu karakter, etiketin metninin bir parçası olarak değerlendirilmez. Bu yalnızca olumlu ve olumsuz ayrımını okumayı kolaylaştırır.

Yalnızca pozitif etiketlerin tümüyle ve negatif etiketlerin hiçbiriyle eşleşen test kuralları test paketine dahil edilir. Bunun, filtrelenen testlere bağımlılıklarla ilgili hata kontrolünün atlandığı anlamına gelmediğini unutmayın.Atlanan testlere bağımlılıkların yine de geçerli olması gerekir (ör. görünürlük kısıtlamaları tarafından engellenmemelidir).

manual etiket anahtar kelimesi, joker karakter içeren çağrılarda blaze test komutu tarafından gerçekleştirilen "test_suite genişletme" işlemiyle yukarıdakilerden farklı şekilde ele alınır. Burada, "manuel" olarak etiketlenen test_suite hedefleri filtrelenir (bu nedenle genişletilmez). Bu davranış, blaze build ve blaze test'nin genel olarak joker hedef kalıplarını ele alma şekliyle tutarlıdır. Paketler, blaze query 'tests(E)' etiketinden bağımsız olarak her zaman tests sorgu işleviyle genişletildiğinden bu durumun blaze query 'tests(E)''nın davranışından açıkça farklı olduğunu unutmayın.manual

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

Birbirini dışlayan etiketlere sahip testler içeren bir test_suite (ör. tüm küçük ve orta testler) gerekiyorsa üç 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 iki kuralı içeren.

tests

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

Herhangi bir dildeki test paketlerinin ve test hedeflerinin listesi.

Dilinden bağımsız olarak tüm *_test karakterleri kabul edilir. Ancak, test çalıştırsalar bile *_binary hedef kabul edilmez. Belirtilen tags ile filtreleme yalnızca doğrudan bu özellikte listelenen testler için yapılır. Bu özellik test_suite içeriyorsa bunların içindeki testler bu test_suite ile filtrelenmez (zaten filtrelenmiş olarak kabul edilir).

tests özelliği belirtilmemişse veya boşsa kural, manual olarak etiketlenmemiş mevcut BUILD dosyasındaki tüm test kurallarını içerecek şekilde varsayılan olarak ayarlanır. Bu kurallar, tag filtrelemeye tabidir.