Yapılandırmalar

Bu sayfada, projenizin derleme şeklini özelleştirmeye yönelik Bazel API'si olan Starlark yapılandırmalarının avantajları ve temel kullanımı ele alınmaktadır. Derleme ayarlarının nasıl tanımlanacağına dair bilgiler ve örnekler içeriyor.

Bu sayede:

  • projeniz için özel işaretler tanımlayarak --define ihtiyacını ortadan kaldırabilirsiniz.
  • üst öğelerinden farklı yapılandırmalardaki (--compilation_mode=opt veya --cpu=arm gibi) depoları yapılandırmak için geçişler yazma
  • kurallara daha iyi varsayılanlar oluşturma (ör. belirli bir SDK ile //my:android_app öğesini otomatik olarak derleme)

ve daha fazlasını (tamamen .bzl dosyalarından) alır (Bazel sürümü gerekmez). Örnekler için bazelbuild/examples deposuna bakın.

Kullanıcı tanımlı derleme ayarları

Derleme ayarı, tek bir yapılandırma bilgisi parçasıdır. Yapılandırmayı bir anahtar/değer eşlemesi olarak düşünebilirsiniz. --cpu=ppc ve --copt="-DFoo" ayarlarını yapmak {cpu: ppc, copt: "-DFoo"} benzeri bir yapılandırma oluşturur. Her giriş bir derleme ayarıdır.

cpu ve copt gibi geleneksel işaretler yerel ayarlardır. Bunların anahtarları tanımlanmıştır ve değerleri yerel Bazel java kodunda ayarlanır. Bazel kullanıcıları bunları yalnızca komut satırı ve yerel olarak sağlanan diğer API'ler aracılığıyla okuyup yazabilir. Yerel işaretlerin ve bunları açığa çıkaran API'lerin değiştirilmesi için yeni sürümün yayınlanması gerekir. Kullanıcı tanımlı derleme ayarları .bzl dosyalarında tanımlanır (dolayısıyla, değişiklikleri kaydetmek için Bazel sürümüne gerek yoktur). Ayrıca, komut satırı üzerinden de ayarlanabilir (flags olarak atanmışlarsa aşağıda daha fazla bilgi bulabilirsiniz) veya kullanıcı tanımlı geçişler aracılığıyla da ayarlanabilir.

Derleme ayarlarını tanımlama

Uçtan uca örneği

build_setting rule() parametresi

Derleme ayarları da diğer kurallar gibi kurallardır ve Starlark rule() işlevinin build_setting özelliği kullanılarak ayırt edilir.

# example/buildsettings/build_settings.bzl
string_flag = rule(
    implementation = _impl,
    build_setting = config.string(flag = True)
)

build_setting özelliği, derleme ayarının türünü tanımlayan bir işlev alır. Tür, bool ve string gibi bir dizi temel Starlark türüyle sınırlıdır. Ayrıntılar için config modülü dokümanları'na bakın. Kuralın uygulama işlevinde daha karmaşık bir yazma yapılabilir. Bu konuyla ilgili daha fazla bilgiyi aşağıda bulabilirsiniz.

config modülünün işlevleri, isteğe bağlı flag boole parametresi alır. Bu parametre, varsayılan olarak false (yanlış) değerine ayarlanır. flag doğru değerine ayarlanırsa derleme ayarı, varsayılan değerler ve geçişler aracılığıyla kullanıcılar tarafından komut satırından yanı sıra kural yazarları tarafından dahili olarak da ayarlanabilir. Tüm ayarlar kullanıcılar tarafından ayarlanamaz. Örneğin, bir kural yazarı olarak test kuralları içinde açmak istediğiniz bazı hata ayıklama modlarınız varsa, kullanıcılara bu özelliği test dışı diğer kuralların içinde ayrı ayrı etkinleştirme izni vermek istemezsiniz.

ctx.build_setting_value kullanımı

Tüm kurallar gibi, derleme ayarı kurallarının uygulama işlevleri vardır. Derleme ayarlarının temel Starlark türü değerine ctx.build_setting_value yöntemi aracılığıyla erişilebilir. Bu yöntem yalnızca derleme ayarı kurallarının ctx nesnelerinde kullanılabilir. Bu uygulama yöntemleri, derleme ayarları değerini doğrudan yönlendirebilir veya bunun üzerinde tür kontrolü ya da daha karmaşık yapı oluşturma gibi ek işler yapabilir. enum türünde bir derleme ayarını şu şekilde uygulayabilirsiniz:

# example/buildsettings/build_settings.bzl
TemperatureProvider = provider(fields = ['type'])

temperatures = ["HOT", "LUKEWARM", "ICED"]

def _impl(ctx):
    raw_temperature = ctx.build_setting_value
    if raw_temperature not in temperatures:
        fail(str(ctx.label) + " build setting allowed to take values {"
             + ", ".join(temperatures) + "} but was set to unallowed value "
             + raw_temperature)
    return TemperatureProvider(type = raw_temperature)

temperature = rule(
    implementation = _impl,
    build_setting = config.string(flag = True)
)

Çok ayarlı dize işaretlerini tanımlama

Dize ayarlarında, işaretin komut satırında veya Bazelrcs'ta birden fazla kez ayarlanmasına olanak tanıyan ek bir allow_multiple parametresi vardır. Varsayılan değerleri hâlâ dize türünde bir öznitelikle ayarlanır:

# example/buildsettings/build_settings.bzl
allow_multiple_flag = rule(
    implementation = _impl,
    build_setting = config.string(flag = True, allow_multiple = True)
)

# example/buildsettings/BUILD
load("//example/buildsettings:build_settings.bzl", "allow_multiple_flag")
allow_multiple_flag(
    name = "roasts",
    build_setting_default = "medium"
)

İşaretin her ayarı tek bir değer olarak ele alınır:

$ bazel build //my/target --//example:roasts=blonde \
    --//example:roasts=medium,dark

Yukarıdaki kod {"//example:roasts": ["blonde", "medium,dark"]} olarak ayrıştırılır ve ctx.build_setting_value, ["blonde", "medium,dark"] listesini döndürür.

Derleme ayarlarını örneklendirme

build_setting parametresiyle tanımlanan kurallar, dolaylı olarak zorunlu bir build_setting_default özelliğine sahiptir. Bu özellik, build_setting parametresinde belirtilenle aynı türü alır.

# example/buildsettings/build_settings.bzl
FlavorProvider = provider(fields = ['type'])

def _impl(ctx):
    return FlavorProvider(type = ctx.build_setting_value)

flavor = rule(
    implementation = _impl,
    build_setting = config.string(flag = True)
)

# example/buildsettings/BUILD
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
    name = "favorite_flavor",
    build_setting_default = "APPLE"
)

Önceden tanımlanmış ayarlar

Uçtan uca örneği

Skylib kitaplığı, özel Starlark yazmak zorunda kalmadan örnekleyebileceğiniz önceden tanımlanmış bir dizi ayar içerir.

Örneğin, sınırlı bir dize değerleri grubunu kabul eden bir ayar tanımlamak için:

# example/BUILD
load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
string_flag(
    name = "myflag",
    values = ["a", "b", "c"],
    build_setting_default = "a",
)

Tam liste için Yaygın derleme ayarı kuralları sayfasına bakın.

Derleme ayarlarını kullanma

Derleme ayarlarına bağlı olarak

Hedef, bir yapılandırma bilgisi parçasını okumak isterse normal bir özellik bağımlılığı aracılığıyla doğrudan derleme ayarına bağlı olabilir.

# example/rules.bzl
load("//example/buildsettings:build_settings.bzl", "FlavorProvider")
def _rule_impl(ctx):
    if ctx.attr.flavor[FlavorProvider].type == "ORANGE":
        ...

drink_rule = rule(
    implementation = _rule_impl,
    attrs = {
        "flavor": attr.label()
    }
)

# example/BUILD
load("//example:rules.bzl", "drink_rule")
load("//example/buildsettings:build_settings.bzl", "flavor")
flavor(
    name = "favorite_flavor",
    build_setting_default = "APPLE"
)
drink_rule(
    name = "my_drink",
    flavor = ":favorite_flavor",
)

Diller, söz konusu dil için tüm kuralların bağlı olduğu standart bir derleme ayarları kümesi oluşturmak isteyebilir. fragments yerel kavramı artık Starlark yapılandırma dünyasında sabit kodlu bir nesne olarak mevcut olmasa da, bu kavramı çevirmenin bir yolu, yaygın örtülü özellik gruplarını kullanmaktır. Örneğin:

# kotlin/rules.bzl
_KOTLIN_CONFIG = {
    "_compiler": attr.label(default = "//kotlin/config:compiler-flag"),
    "_mode": attr.label(default = "//kotlin/config:mode-flag"),
    ...
}

...

kotlin_library = rule(
    implementation = _rule_impl,
    attrs = dicts.add({
        "library-attr": attr.string()
    }, _KOTLIN_CONFIG)
)

kotlin_binary = rule(
    implementation = _binary_impl,
    attrs = dicts.add({
        "binary-attr": attr.label()
    }, _KOTLIN_CONFIG)

Komut satırında derleme ayarlarını kullanma

Çoğu yerel işarete benzer şekilde, bayrak olarak işaretlenmiş derleme ayarlarını belirlemek için komut satırını kullanabilirsiniz. Derleme ayarının adı, name=value söz dizimini kullanan tam hedef yoludur:

$ bazel build //my/target --//example:string_flag=some-value # allowed
$ bazel build //my/target --//example:string_flag some-value # not allowed

Özel boole söz dizimi desteklenir:

$ bazel build //my/target --//example:boolean_flag
$ bazel build //my/target --no//example:boolean_flag

Derleme ayarı takma adlarını kullanma

Komut satırında okumayı kolaylaştırmak için derleme ayarı hedef yolunuz için bir takma ad belirleyebilirsiniz. Takma adlar, yerel işaretlere benzer şekilde çalışır ve ayrıca çift kısa çizgili seçenek söz diziminden yararlanır.

--flag_alias=ALIAS_NAME=TARGET_PATH adresini .bazelrc hesabınıza ekleyerek takma ad belirleyin . Örneğin, coffee olarak takma ad ayarlamak için:

# .bazelrc
build --flag_alias=coffee=//experimental/user/starlark_configurations/basic_build_setting:coffee-temp

En İyi Uygulama: Bir takma ad birkaç kez ayarlandığında en yeni takma ad öncelikli olur. Sonuçların istenmeyen bir şekilde ayrıştırılmasını önlemek için benzersiz takma ad adları kullanın.

Takma addan yararlanmak için derleme ayarı hedef yolunun yerine yazın. Yukarıdaki coffee örneği, kullanıcının .bazelrc ayarında ayarlanmıştır:

$ bazel build //my/target --coffee=ICED

yerine

$ bazel build //my/target --//experimental/user/starlark_configurations/basic_build_setting:coffee-temp=ICED

En İyi Uygulama: Komut satırında takma ad belirlemek mümkün olsa da bunları .bazelrc içinde bırakmak komut satırı karmaşasını azaltır.

Etiket türünde derleme ayarları

Uçtan uca örneği

Diğer derleme ayarlarının aksine etiket türü ayarlar, build_setting kural parametresi kullanılarak tanımlanamaz. Bunun yerine, Bazel'ın iki yerleşik kuralı vardır: label_flag ve label_setting. Bu kurallar, derleme ayarının ayarlandığı gerçek hedefin sağlayıcılarını yönlendirir. label_flag ve label_setting, geçişlerle okunabilir/yazılabilir ve label_flag, kullanıcı tarafından diğer build_setting kuralları gibi ayarlanabilir. Tek farkları, özel olarak tanımlanamayacak olmalarıdır.

Etiket türünde ayarlar, sonuçta geç sınırlanmış varsayılanların işlevselliğinin yerini alacaktır. Geç sınırlanmış varsayılan özellikler, nihai değerleri yapılandırmadan etkilenebilen Etiket türünde özelliklerdir. Starlark'ta bu, configuration_field API'nin yerini alacak.

# example/rules.bzl
MyProvider = provider(fields = ["my_field"])

def _dep_impl(ctx):
    return MyProvider(my_field = "yeehaw")

dep_rule = rule(
    implementation = _dep_impl
)

def _parent_impl(ctx):
    if ctx.attr.my_field_provider[MyProvider].my_field == "cowabunga":
        ...

parent_rule = rule(
    implementation = _parent_impl,
    attrs = { "my_field_provider": attr.label() }
)


# example/BUILD
load("//example:rules.bzl", "dep_rule", "parent_rule")

dep_rule(name = "dep")

parent_rule(name = "parent", my_field_provider = ":my_field_provider")

label_flag(
    name = "my_field_provider",
    build_setting_default = ":dep"
)

Ayarları oluşturun ve select()

Uçtan uca örneği

Kullanıcılar, select() kullanarak derleme ayarlarında özellikleri yapılandırabilir. Derleme ayarı hedefleri, config_setting öğesinin flag_values özelliğine geçirilebilir. Yapılandırmayla eşleştirilecek değer String olarak aktarılır ve ardından eşleştirme için derleme ayarı türüne ayrıştırılır.

config_setting(
    name = "my_config",
    flag_values = {
        "//example:favorite_flavor": "MANGO"
    }
)

Kullanıcı tanımlı geçişler

Yapılandırma geçişi, dönüşümü derleme grafiğinde yapılandırılmış bir hedeften diğerine eşler.

Bunları belirleyen kurallar özel bir özellik içermelidir:

  "_allowlist_function_transition": attr.label(
      default = "@bazel_tools//tools/allowlists/function_transition_allowlist"
  )

Geçişler ekleyerek yapı grafiğinizin boyutunu kolayca inceleyebilirsiniz. Bu işlem, bu kuralın hedeflerini oluşturabileceğiniz paketlerde bir izin verilenler listesi ayarlar. Yukarıdaki kod bloğunda bulunan varsayılan değer, her şeyi izin verilenler listesine ekler. Ancak kuralınızı kullanan kişileri kısıtlamak istiyorsanız bu özelliği kendi özel izin verilenler listenize işaret edecek şekilde ayarlayabilirsiniz. Geçişlerin derleme performansınızı nasıl etkileyebileceğini anlamak için öneri veya yardım almak isterseniz bazel-discuss@googlegroups.com adresiyle iletişime geçin.

Tanımlama

Geçişler, kurallar arasındaki yapılandırma değişikliklerini tanımlar. Örneğin, "bağımlılığımı üst öğesinden farklı bir CPU için derleyin" gibi bir istek geçiş ile işlenir.

Resmî olarak geçiş, giriş yapılandırmasından bir veya daha fazla çıkış yapılandırmasına geçiştir. Çoğu geçiş, "--cpu=ppc ile giriş yapılandırmasını geçersiz kıl" gibi 1:1 şeklinde gerçekleştirilir. Bire bir veya daha fazla geçişler de mevcut olabilir ancak özel kısıtlamalara tabi olabilir.

Starlark'ta geçişler, tıpkı kurallar gibi bir tanımlayıcı transition() işlev ve bir uygulama işleviyle tanımlanır.

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {"//example:favorite_flavor" : "MINT"}

hot_chocolate_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//example:favorite_flavor"]
)

transition() işlevi bir uygulama işlevi, okunacak bir derleme ayarları(inputs) ve yazılacak derleme ayarları (outputs) alır. Uygulama işlevinin iki parametresi vardır: settings ve attr. settings, transition() için inputs parametresinde tanımlanan tüm ayarları içeren bir sözlük {String:Object}.

attr, geçişin eklendiği kuralın özelliklerini ve değerlerini içeren bir sözlüktür. Giden uç geçişi olarak eklendiğinde, bu özelliklerin değerlerinin tümü post-select() çözünürlüğü yapılandırılır. Gelen uç geçişi olarak eklendiğinde, attr değerini çözümlemek için seçici kullanan hiçbir özellik içermez. --foo üzerinde gelen uç geçişi bar özelliğini okur ve ardından --foo üzerinde bar özelliğini ayarlamak için seçim yaparsa gelen uç geçişinin geçişte yanlış bar değerini okuma ihtimali vardır.

Uygulama işlevi, uygulanacak yeni derleme ayarları değerlerinin sözlüğü (veya birden fazla çıkış yapılandırmasına sahip geçişlerde sözlük listesi) döndürmelidir. Döndürülen sözlük anahtar kümeleri, tam olarak geçiş işlevinin outputs parametresine iletilen derleme ayarları grubunu içermelidir. Bir derleme ayarı geçiş sırasında gerçekten değişmemiş olsa bile bu durum geçerlidir. Orijinal değeri, döndürülen sözlükte açıkça geçirilmelidir.

1:2+ geçişleri tanımlama

Uçtan uca örneği

Giden uç geçişi, tek bir giriş yapılandırmasını iki veya daha fazla çıkış yapılandırmasıyla eşleyebilir. Bu, birden çok mimariye sahip kodu bir araya getiren kuralları tanımlamak için kullanışlıdır.

1:2+ geçişleri, geçiş uygulama işlevinde bir sözlük listesi döndürülerek tanımlanır.

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return [
        {"//example:favorite_flavor" : "LATTE"},
        {"//example:favorite_flavor" : "MOCHA"},
    ]

coffee_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//example:favorite_flavor"]
)

Ayrıca, kural uygulama işlevinin bağımlılıkları tek tek okumak için kullanabileceği özel anahtarlar da ayarlayabilirler:

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {
        "Apple deps": {"//command_line_option:cpu": "ppc"},
        "Linux deps": {"//command_line_option:cpu": "x86"},
    }

multi_arch_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//command_line_option:cpu"]
)

Geçiş ekleme

Uçtan uca örneği

Geçişler iki yere eklenebilir: gelen kenarlar ve giden kenarlar. Etkili bir şekilde bu durum, kuralların kendi yapılandırmalarını (gelen uç geçişi) ve bağımlılıklarının yapılandırmalarını (giden uç geçişi) geçirebileceği anlamına gelir.

NOT: Şu anda Starlark geçişlerini yerel kurallara eklemenin bir yolu yoktur. Bunu yapmanız gerekirse geçici çözümler bulma konusunda yardım almak içinbazel-discuss@googlegroups.com adresinden bizimle iletişime geçebilirsiniz.

Gelen kenar geçişleri

Gelen uç geçişleri, rule() öğesinin cfg parametresine bir transition nesnesi (transition() tarafından oluşturulan) eklenerek etkinleştirilir:

# example/rules.bzl
load("example/transitions:transitions.bzl", "hot_chocolate_transition")
drink_rule = rule(
    implementation = _impl,
    cfg = hot_chocolate_transition,
    ...

Gelen kenar geçişleri 1:1 geçişler olmalıdır.

Giden uç geçişleri

Giden uç geçişleri, bir özelliğin cfg parametresine transition nesnesi (transition() tarafından oluşturulan) eklenerek etkinleştirilir:

# example/rules.bzl
load("example/transitions:transitions.bzl", "coffee_transition")
drink_rule = rule(
    implementation = _impl,
    attrs = { "dep": attr.label(cfg = coffee_transition)}
    ...

Giden sınır geçişleri 1:1 veya 1:2 veya daha uzun olabilir.

Bu anahtarları nasıl okuyacağınızı öğrenmek için Geçişli özelliklere erişme bölümüne bakın.

Yerel seçeneklerdeki geçişler

Uçtan uca örneği

Ayrıca Starlark geçişleri, seçenek adına özel bir önek ekleyerek yerel derleme yapılandırma seçeneklerinde okuma ve yazma işlemleri bildirebilir.

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {"//command_line_option:cpu": "k8"}

cpu_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//command_line_option:cpu"]

Desteklenmeyen yerel seçenekler

Bazel, --define üzerinde "//command_line_option:define" ile geçiş yapılmasını desteklemiyor. Bunun yerine özel bir oluşturma ayarı kullanın. Genel olarak, derleme ayarlarının sunulması için --define yeni kullanımları önerilmez.

Bazel, --config üzerinde geçiş yapmayı desteklemiyor. Bunun nedeni, --config öğesinin diğer işaretlere genişleyen bir "genişletme" işareti olmasıdır.

--config hizmetinin, derleme yapılandırmasını etkilemeyen --spawn_strategy gibi işaretler içerebilir. Bazel, tasarımı gereği bu tür işaretleri tek tek hedeflere bağlayamaz. Bu, bunları geçişlerde uygulamanın tutarlı bir yolu olmadığı anlamına gelir.

Geçici bir çözüm olarak, geçişinizdeki yapılandırmanın bir parçası olan işaretleri açıkça listeleyebilirsiniz. Bu, --config adlı öğenin iki yerde genişletilmesini gerektirir. Bu, bilinen bir kullanıcı arayüzü sorunudur.

Birden fazla derleme ayarına izin verildiğinde geçişler

Birden çok değere izin veren derleme ayarları yapılırken, ayarın değeri bir liste ile ayarlanmalıdır.

# example/buildsettings/build_settings.bzl
string_flag = rule(
    implementation = _impl,
    build_setting = config.string(flag = True, allow_multiple = True)
)

# example/BUILD
load("//example/buildsettings:build_settings.bzl", "string_flag")
string_flag(name = "roasts", build_setting_default = "medium")

# example/transitions/rules.bzl
def _transition_impl(settings, attr):
    # Using a value of just "dark" here will throw an error
    return {"//example:roasts" : ["dark"]},

coffee_transition = transition(
    implementation = _transition_impl,
    inputs = [],
    outputs = ["//example:roasts"]
)

İşlemsiz geçişler

Bir geçiş {}, [] veya None döndürürse bu, tüm ayarları orijinal değerlerinde tutmanın kısaltmasıdır. Bu yöntem, her bir sonucu açık bir şekilde ayarlamaktan daha kullanışlı olabilir.

# example/transitions/transitions.bzl
def _impl(settings, attr):
    _ignore = (attr)
    if settings["//example:already_chosen"] is True:
      return {}
    return {
      "//example:favorite_flavor": "dark chocolate",
      "//example:include_marshmallows": "yes",
      "//example:desired_temperature": "38C",
    }

hot_chocolate_transition = transition(
    implementation = _impl,
    inputs = ["//example:already_chosen"],
    outputs = [
        "//example:favorite_flavor",
        "//example:include_marshmallows",
        "//example:desired_temperature",
    ]
)

Geçişli özelliklere erişme

Uçtan uca örneği

Giden bir kenara geçiş eklerken (geçişin 1:1 veya 1:2+ olup olmadığına bakılmaksızın), ctx.attr henüz listelenmemişse liste olmaya zorlanır. Bu listedeki öğelerin sırası belirtilmemiş.

# example/transitions/rules.bzl
def _transition_impl(settings, attr):
    return {"//example:favorite_flavor" : "LATTE"},

coffee_transition = transition(
    implementation = _transition_impl,
    inputs = [],
    outputs = ["//example:favorite_flavor"]
)

def _rule_impl(ctx):
    # Note: List access even though "dep" is not declared as list
    transitioned_dep = ctx.attr.dep[0]

    # Note: Access doesn't change, other_deps was already a list
    for other dep in ctx.attr.other_deps:
      # ...


coffee_rule = rule(
    implementation = _rule_impl,
    attrs = {
        "dep": attr.label(cfg = coffee_transition)
        "other_deps": attr.label_list(cfg = coffee_transition)
    })

Geçiş 1:2+ ise ve özel anahtarlar belirliyorsa her anahtarın bağımsız bölümlerini okumak için ctx.split_attr kullanılabilir:

# example/transitions/rules.bzl
def _impl(settings, attr):
    _ignore = (settings, attr)
    return {
        "Apple deps": {"//command_line_option:cpu": "ppc"},
        "Linux deps": {"//command_line_option:cpu": "x86"},
    }

multi_arch_transition = transition(
    implementation = _impl,
    inputs = [],
    outputs = ["//command_line_option:cpu"]
)

def _rule_impl(ctx):
    apple_dep = ctx.split_attr.dep["Apple deps"]
    linux_dep = ctx.split_attr.dep["Linux deps"]
    # ctx.attr has a list of all deps for all keys. Order is not guaranteed.
    all_deps = ctx.attr.dep

multi_arch_rule = rule(
    implementation = _rule_impl,
    attrs = {
        "dep": attr.label(cfg = multi_arch_transition)
    })

Tam örneği burada bulabilirsiniz.

Platformlar ve araç zincirleriyle entegrasyon

Günümüzde --cpu ve --crosstool_top gibi birçok yerel işaretleme, araç zinciri çözünürlüğüyle ilgilidir. Gelecekte, bu tür işaretlerdeki açık geçişlerin yerini muhtemelen hedef platformda geçiş alacaktır.

Bellek ve performansla ilgili dikkat edilmesi gerekenler

Derlemenize geçişler, dolayısıyla yeni yapılandırmalar eklemenin bir maliyeti vardır: daha büyük derleme grafikleri, daha kolay anlaşılabilir derleme grafikleri ve daha yavaş derlemeler. Derleme kurallarınızda geçişleri kullanmayı düşünürken bu maliyetleri göz önünde bulundurmanızı öneririz. Aşağıda, bir geçişin yapı grafiğinizde nasıl üstel büyüme oluşturabileceğine dair bir örnek verilmiştir.

Kötü davranış sergileyen derlemeler: örnek olay

Ölçeklenebilirlik grafiği

Şekil 1. Bir üst düzey hedefi ve bağımlılıklarını gösteren ölçeklenebilirlik grafiği.

Bu grafikte, a //pkg:1_0 ve //pkg:1_1 olmak üzere iki hedefe bağlı olan //pkg:app üst düzey bir hedef gösterilmektedir. Bu hedeflerin her ikisi de iki hedefe bağlıdır, //pkg:2_0 ve //pkg:2_1. Bu hedeflerin her ikisi de iki hedefe bağlıdır, //pkg:3_0 ve //pkg:3_1. Bu, her ikisi de tek bir hedefe (//pkg:dep) bağlı olan //pkg:n_0 ve //pkg:n_1 tarihine kadar devam eder.

//pkg:app oluşturulması için \(2n+2\) hedefler gerekli:

  • //pkg:app
  • //pkg:dep
  • \(i\) \([1..n]\)için //pkg:i_0 ve //pkg:i_1

Bir flag'in (--//foo:owner=<STRING> ve //pkg:i_b) geçerli olduğunu implement düşünün

depConfig = myConfig + depConfig.owner="$(myConfig.owner)$(b)"

Diğer bir deyişle //pkg:i_b, tüm işlemleri için --owner öğesinin eski değerine b ekler.

Bu, aşağıdaki yapılandırılmış hedefleri oluşturur:

//pkg:app                              //foo:owner=""
//pkg:1_0                              //foo:owner=""
//pkg:1_1                              //foo:owner=""
//pkg:2_0 (via //pkg:1_0)              //foo:owner="0"
//pkg:2_0 (via //pkg:1_1)              //foo:owner="1"
//pkg:2_1 (via //pkg:1_0)              //foo:owner="0"
//pkg:2_1 (via //pkg:1_1)              //foo:owner="1"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_0)  //foo:owner="00"
//pkg:3_0 (via //pkg:1_0 → //pkg:2_1)  //foo:owner="01"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_0)  //foo:owner="10"
//pkg:3_0 (via //pkg:1_1 → //pkg:2_1)  //foo:owner="11"
...

//pkg:dep, \(2^n\) yapılandırılmış hedefler oluşturur: config.owner= \(b_i\) tüm \(b_i\) ürünleri \(\{0,1\}\)için "\(b_0b_1...b_n\)".

Bu durum, derleme grafiğini hedef grafikten katlanarak büyür ve buna karşılık gelen bellek ve performans sonuçları olur.

YAPILACAKLAR: Bu sorunları gidermek ve bu sorunları gidermek için stratejiler ekleyin.

Daha fazla bilgi

Derleme yapılandırmalarını değiştirme hakkında daha fazla bilgi için şu konulara bakın: