Genel Kurallar

Kurallar

• takma ad
• config_setting
• filegroup
• genquery
• genrule
• starlark_doc_extract
• 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 ad oluşturma yalnızca "normal" hedefler için çalışır. Özellikle package_group ve test_suite için takma ad kullanılamaz.

Takma ad, bir hedefin yeniden adlandırılmasının çok sayıda dosyada değişiklik yapılmasını gerektirdiği büyük depolarda yararlı olabilir. Takma ad kuralını birden fazla hedef için yeniden kullanmak istiyorsanız select işlev çağrısını depolamak için de kullanabilirsiniz.

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 yok sayı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. Bunlar, --target_environment komut satırı seçeneğinde de desteklenmez.

Örnekler

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

Bağımsız değişkenler

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ı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 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 örnek, x86_64 mimarisine ve glibc sürüm 2.25'e sahip bir platformu hedefleyen tüm derlemelerle eşleşir ve //example:glibc_2_25 etiketine sahip bir constraint_value bulunduğu varsayılır. 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",
      ]
  )
  

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şiklik gösterir. Örneğin, --copt aynı örnekte birden fazla değeri desteklemez: --copt=a,b, ["a,b"] değerini üretirken --copt=a --copt=b, ["a", "b"] değerini üretir (yani values = { "copt": "a,b" }, ilkiyle eşleşir ancak ikincisiyle eşleşmez). Ancak --ios_multi_cpus (Apple kuralları için) 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 kullanabilirsiniz, ancak bu daha zayıf destek sağlar 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

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

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

dosya grubu

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

Bir hedef grubunun çıktılarını tek bir etiket altında toplamak için filegroup değerini kullanın.

Hedeflerin çıktıları dışında, aynı şekilde toplanmayan birçok özelliği olduğundan filegroup, hedefleri komut satırında veya başka bir kuralın özelliğinde listelemenin yerini almaz. Ancak yine de bazı durumlarda kullanışlıdır. Örneğin, bir genrule kuralının srcs özelliğinde veya *_binary kuralının data özelliğinde.

Dizinlere doğrudan referans vermek yerine filegroup kullanılması önerilir. Derleme sistemi dizin altındaki tüm dosyalar hakkında tam bilgiye sahip olmadığından, bu dosyalar değiştiğinde derlemeler yeniden oluşturulamayabilir. Bu nedenle dizinlere doğrudan referans verilmesi önerilmez. 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",
        "//a/library:target",
        "//a/binary:target",
    ],
)

Dilerseniz testdata dizinini tamamen taramak 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

genquery

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(), Bazel sorgu dilinde belirtilen bir sorguyu çalıştırır ve sonucu bir dosyaya aktarır.

Derlemenin tutarlılığını sağlamak için sorgunun yalnızca scope özelliğinde belirtilen hedeflerin geçişli kapanışı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 olmamasını sağlamanın en kolay yolu, sorgu ifadesinde belirtilenle aynı etiketleri kapsam içinde belirtmektir.

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).

--output=graph|minrank|maxrank hariç olmak üzere veya üst düzey işlev olarak somepath kullanıldığında elde edilen sorgu çıkışı, belirleyici çıktıyı uygulamak için sözlüksel 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ılmaktadır.

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

Bağımsız değişkenler

genrule

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.

Genrule, görev için belirli bir kural yoksa kullanabileceğiniz genel derleme kurallarıdır. Örneğin, tek satırlık bir Bash dokümanı çalıştırabilirsiniz. Yine de C++ dosyalarını derlemeniz gerekiyorsa mevcut cc_* kurallarına bağlı kalın. Tüm ağır işlemler sizin yerinize zaten yapılmıştır.

Genrule öğesinin, komut bağımsız değişkenini yorumlamak için kabuk gerektirdiğini unutmayın. PATH'te bulunan herhangi bir programa referans vermek de kolaydır ancak bu, komutun hermetik olmasını engeller ve komut tekrar oluşturulamayabilir. Yalnızca tek bir araç çalıştırmanız gerekiyorsa bunun yerine run_binary'yi kullanabilirsiniz.

Diğer tüm işlemler gibi, genrules tarafından oluşturulan işlem de çalışma dizini hakkında hiçbir varsayımda bulunmamalıdır. Bazel, yalnızca beyan edilen girişlerin $(location) etiketi için döndürdüğü yolda bulunacağını garanti eder. Örneğin, işlem korumalı alanda veya uzaktan çalıştırılırsa çalışma dizini, korumalı alanın uygulanması veya uzaktan yürütme işlemine göre belirlenir. Doğrudan çalıştırılırsa (standalone stratejisi kullanılarak) çalışma dizini, yürütme kökü yani bazel info execution_root sonucu olur.

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 de dahil olmak üzere özel dağıtımlar 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 Derlemeyle İlgili Konular

Çapraz derleme hakkında daha fazla bilgi için kullanıcı kılavuzunu inceleyin.

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 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. Genrule'lar yalnızca dosya ve çalıştırma dosyaları düzeyinde çalışır.

Özel Durumlar

Exec-exec derlemesi: Bazı durumlarda derleme sisteminin, çıkışın derleme sırasında da yürütülebilmesi için genrule çalıştırması gerekir. Örneğin, bir genrule, daha sonra başka bir Genrule tarafından kullanılacak bir özel derleyici derlerse ilkinin, yürütme yapılandırması için çıktısını oluşturması gerekir. Çünkü derleyici bu aşamada diğer genel kuralda da çalışır. 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 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 tekrarlanabilir olmasını sağlamak için kullanıcının kabuk ortamında tanımlanan çoğu değişken, genrule komutunun 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, hata durumunda çıkış dosyalarını da kaldırır.

Genel Tavsiye

• Bir genel kural 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 kişilerin 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. Ö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).
• Sembol 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 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 filegroup özelliğinin nasıl kullanılacağı ve başka bir genrule öğesinin çıkışları 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

starlark_doc_extract

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 sonucu, Bazel kaynak ağacındaki stardoc_output.proto bölümünde tanımlandığı gibi bir ModuleInfo ikili programıdır.

Örtülü çıkış hedefleri

• name.binaryproto (varsayılan çıkış): ModuleInfo ikili proto.
• 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. Bu API, temel olarak Stardoc tarafından şirket içi kullanım için tasarlanmıştır.

Bağımsız değişkenler

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 "faydalı" olarak kabul edilen bir dizi testi tanımlar. Bu sayede projeler, "kontrol etmeden önce çalıştırmanız gereken testler", "projemizin stres testleri" veya "tüm küçük testler" gibi test setleri tanımlayabilir. bazel test komutu şu organizasyona uyar: bazel test //some/test:suite gibi bir çağrı için Bazel ö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 Bazel 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 bir 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