Değişken Oluşturma

Sorun bildir Kaynağı görüntüle Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

"Marka" değişkenleri, "Marka değişkeni değiştirme işlemine tabidir" olarak işaretlenen özellikler için kullanılabilen özel bir genişletilebilir dize değişkeni sınıfıdır.

Örneğin, kullanıcı tarafından oluşturulan derleme işlemlerine belirli araç zinciri yollarını yerleştirmek için kullanılabilir.

Bazel, tüm hedeflerde kullanılabilen önceden tanımlanmış değişkenlerin yanı sıra bağımlılık hedeflerinde tanımlanan ve yalnızca bunlara bağlı hedeflerde kullanılabilen özel değişkenler de sağlar.

"Make" teriminin nedeni geçmişe dayanmaktadır: Bu değişkenlerin söz dizimi ve semantiği başlangıçta GNU Make ile eşleşecek şekilde tasarlanmıştır.

Kullan

"Değişken oluşturma" yerine geçirme işlemine tabi olarak işaretlenen özellikler, FOO "Marka" değişkenine aşağıdaki şekilde referans verebilir:

my_attr = "prefix $(FOO) suffix"

Diğer bir deyişle, $(FOO) ile eşleşen tüm alt dizeler FOO değerine genişletilir. Bu değer "bar" ise nihai dize şu şekilde olur:

my_attr = "prefix bar suffix"

FOO, tüketen hedef tarafından bilinen bir değişkene karşılık gelmiyorsa Bazel hata vererek başarısız olur.

Adları harf olmayan semboller olan "Make" değişkenlerine (ör. @) parantez olmadan yalnızca dolar işareti kullanılarak da referans verilebilir. Örneğin:

my_attr = "prefix $@ suffix"

$ karakterini dize değişmezi olarak yazmak için (ör. değişken genişlemesini önlemek için) $$ yazın.

Önceden tanımlanmış değişkenler

Önceden tanımlanmış "Marka" değişkenlerine, herhangi bir hedefte "Marka değişkeni yerine koyma işlemine tabidir" olarak işaretlenmiş tüm özellikler tarafından referans verilebilir.

Belirli bir derleme seçenekleri grubu için bu değişkenlerin listesini ve değerlerini görmek üzere

bazel info --show_make_env [build options]

ve büyük harflerle yazılmış en üstteki çıkış satırlarına bakın.

Önceden tanımlanmış değişken örneğini inceleyin.

Toolchain seçeneği değişkenleri

Yol değişkenleri

  • BINDIR: Hedef mimari için oluşturulan ikili ağacın temeli.

    Ana makine mimarisinde derleme sırasında çalışan programlar için farklı bir ağacın kullanılabileceğini unutmayın. Bu, çapraz derlemeyi desteklemek içindir.

    Bir genrule içinden bir araç çalıştırmak istiyorsanız yolunu almanın önerilen yolu $(execpath toolname)'dir. Burada toolname, genrule'nın tools özelliğinde listelenmelidir.

  • GENDIR: Hedef mimari için oluşturulan kod ağacının tabanı.

Makine mimarisi değişkenleri

  • TARGET_CPU: Hedef mimarinin CPU'su (ör. k8).

Önceden tanımlanmış genrule değişkenleri

Aşağıdaki özellikler özellikle genrule's cmd özelliği için kullanılabilir ve bu özelliğin çalışması için genellikle önemlidir.

Önceden tanımlanmış genrule değişkenlerine ilişkin bir örneği inceleyin.

  • OUTS: genrule kullanıcısının outs listesi. Yalnızca bir çıkış dosyanız varsa $@ simgesini de kullanabilirsiniz.
  • SRCS: genrule'nin srcs listesi (veya daha doğrusu: srcs listesindeki etiketlere karşılık gelen dosyaların yol adları). Yalnızca bir kaynak dosyanız varsa $< simgesini de kullanabilirsiniz.
  • <: Tek bir dosya ise SRCS. Aksi takdirde derleme hatası tetiklenir.
  • @: Tek bir dosya ise OUTS. Aksi takdirde derleme hatası tetiklenir.

  • RULEDIR: Hedefin çıkış dizini, yani genfiles veya bin ağacında hedefi içeren paketin adına karşılık gelen dizin. //my/pkg:my_genrule için bu işlem her zaman my/pkg ile sonuçlanır. //my/pkg:my_genrule'nın çıktıları alt dizinlerde olsa bile bu durum değişmez.

  • @D: Çıkış dizini. outs bir giriş içeriyorsa bu, söz konusu dosyayı içeren dizine genişletilir. Birden fazla girişi varsa bu, genfiles ağacında paketin kök dizinine genişletilir. Tüm çıkış dosyaları aynı alt dizinde olsa bile!

    Not: RULEDIR, @D'e kıyasla daha basit bir anlambilime sahip olduğundan ve çıkış dosyalarının sayısından bağımsız olarak aynı şekilde davrandığından RULEDIR'i kullanın.

    Genrule'un geçici ara dosyalar oluşturması gerekiyorsa (örneğin, derleyici gibi başka bir araç kullanmanın sonucu olarak) bunları @D'ya yazmaya çalışmalı (/tmp da yazılabilir olsa da) ve bitirmeden önce kaldırmalıdır.

    Özellikle giriş içeren dizinlere yazmaktan kaçının. Bunlar, salt okunur dosya sistemlerinde olabilir. Aksi takdirde, kaynak ağaç çöp kutusuna taşınır.

Önceden tanımlanmış kaynak/çıkış yolu değişkenleri

Önceden tanımlanmış execpath, execpaths, rootpath, rootpaths, location ve locations değişkenleri, etiket parametrelerini (ör. $(execpath //foo:bar)) alır ve bu etiketle belirtilen dosya yollarının yerine geçer.

Kaynak dosyalar için bu, çalışma alanınızın kök dizinine göre olan yoldur. Kuralların çıkışları olan dosyalar için bu, dosyanın çıkış yoludur (aşağıdaki çıkış dosyaları açıklamasına bakın).

Önceden tanımlanmış yol değişkenleri örneğini inceleyin.

  • execpath: Bazel'in derleme işlemlerini çalıştırdığı execroot'un altındaki yolu belirtir.

    Yukarıdaki örnekte Bazel, çalışma alanınızın kök dizininde bazel-myproject sembolik bağlantısıyla bağlanan dizindeki tüm derleme işlemlerini çalıştırır. Kaynak dosya empty.source, bazel-myproject/testapp/empty.source yoluna bağlıdır. Bu nedenle, yürütülebilir dosya yolu (kökün altındaki alt yol) testapp/empty.source olur. Bu, derleme işlemlerinin dosyayı bulmak için kullanabileceği yoldur.

    Çıkış dosyaları benzer şekilde hazırlanır ancak alt yolla da öneklenir bazel-out/cpu-compilation_mode/bin (veya araçların çıkışları için: bazel-out/cpu-opt-exec-hash/bin). Yukarıdaki örnekte, //testapp:app, show_app_output'ün tools özelliğinde göründüğü için bir araçtır. Bu nedenle, çıkış dosyası app, bazel-myproject/bazel-out/cpu-opt-exec-hash/bin/testapp/app konumuna yazılır. Bu nedenle, yürütme yolu bazel-out/cpu-opt-exec-hash/bin/testapp/app olur. Bu ek önek, sonuçların birbirini ezmeden aynı derlemede örneğin iki farklı CPU için aynı hedefi oluşturmayı mümkün kılar.

    Bu değişkene iletilen etiket tam olarak bir dosyayı temsil etmelidir. Kaynak dosyaları temsil eden etiketler için bu durum otomatik olarak geçerlidir. Kuralları temsil eden etiketler için kural tam olarak bir çıkış oluşturmalıdır. Bu değer yanlışsa veya etiket hatalı biçimlendirilmişse derleme hata vererek başarısız olur.

  • rootpath: Oluşturulan bir ikilinin, çalışma zamanında bir bağımlılığı bulmak için kullanabileceği yolu, ana depoya karşılık gelen runfiles dizininin alt dizinine göre belirtir. Not: Bu özellik yalnızca --enable_runfiles etkinse çalışır. Bu özellik, Windows'da varsayılan olarak etkin değildir. Platformlar arası destek için bunun yerine rlocationpath kullanın.

    Bu, execpath'ya benzer ancak yukarıda açıklanan yapılandırma ön eklerini kaldırır. Yukarıdaki örnekte bu, hem empty.source hem de app özelliklerinin tamamen çalışma alanına göre yollar kullandığı anlamına gelir: testapp/empty.source ve testapp/app.

    Harici bir depodaki dosyanın rootpath repo, ../repo/ ile başlar ve ardından depoya göre göreceli yol gelir.

    Bu işlev, execpath ile aynı "yalnızca bir çıktı" şartlarına sahiptir.

  • rlocationpath: Oluşturulan bir ikilinin, çalışma zamanında bir bağımlılığı bulmak için runfiles kitaplığının Rlocation işlevine iletebileceği yol. Bu bağımlılık, runfiles dizininde (varsa) veya runfiles manifest'i kullanılarak bulunabilir.

    Bu, rootpath ile benzer şekilde yapılandırma önekleri içermez ancak her zaman depo adıyla başlaması bakımından farklıdır. Yukarıdaki örnekte bu, empty.source ve app öğelerinin aşağıdaki yollarla sonuçlandığı anlamına gelir: myproject/testapp/empty.source ve myproject/testapp/app.

    Harici bir depodaki dosyanın rlocationpath repo, repo/ ile başlar ve ardından depoya göre göreceli yol gelir.

    Bu yolu bir ikiliye iletmek ve çalışma zamanında bağımlılıkları bulmak için tercih edilen yaklaşım, runfiles kitaplıklarını kullanarak dosya sistemi yoluna çözümlemektir. rootpath ile karşılaştırıldığında, tüm platformlarda ve runfiles dizini kullanılamıyor olsa bile çalışması avantaj sağlar.

    Bu işlev, execpath ile aynı "yalnızca bir çıktı" şartlarına sahiptir.

  • location: Genişletilen özelliğe bağlı olarak execpath veya rootpath için eş anlamlıdır. Bu, Starlark öncesi eski bir davranıştır ve belirli bir kural için ne yaptığını gerçekten bilmiyorsanız önerilmez. Ayrıntılar için #2475 numaralı soruna bakın.

execpaths, rootpaths, rlocationpaths ve locations, sırasıyla execpath, rootpath, rlocationpaths ve location öğelerinin çoğul biçimleridir. Birden fazla çıktı üreten plak şirketleri desteklenir. Bu durumda her çıktı, boşlukla ayrılarak listelenir. Sıfır çıkışlı kurallar ve hatalı biçimlendirilmiş etiketler derleme hatalarına neden olur.

Referans verilen tüm etiketler, tüketen hedefin srcs, çıkış dosyalarında veya deps içinde görünmelidir. Aksi takdirde derleme başarısız olur. C++ hedefleri, data içindeki etiketlere de referans verebilir.

Etiketlerin standart biçimde olması gerekmez: foo, :foo ve //somepkg:foo kabul edilir.

Özelleştirilebilen değişkenler

Özel "Marka" değişkenlerine, "Marka değişkeni değiştirme işlemine tabi" olarak işaretlenen tüm özellikler tarafından başvurulabilir ancak yalnızca bu değişkenleri tanımlayan diğer hedeflere bağlı olan hedeflerde kullanılabilir.

En iyi uygulama olarak, tüm değişkenler özel olmalıdır. Ancak bunları temel Bazel'e dahil etmek için gerçekten iyi bir neden varsa bu kural geçerli değildir. Bu, Bazel'in, hedef tüketen değişkenlerin önemsemeyebileceği, potansiyel olarak maliyetli bağımlılıkları yüklemesini önler.

C++ toolchain değişkenleri

Aşağıdakiler C++ araç zinciri kurallarında tanımlanır ve toolchains = ["@bazel_tools//tools/cpp:current_cc_toolchain"] ayarını yapan tüm kurallar tarafından kullanılabilir. java_binary gibi bazı kurallar, C++ araç zincirini kural tanımlarına dolaylı olarak dahil eder. Bu değişkenleri otomatik olarak devralırlar.

Yerleşik C++ kuralları, "derleyiciyi üzerinde çalıştır"dan çok daha karmaşıktır. *SAN, ThinLTO, modüllü/modülsüz gibi çeşitli derleme modlarının yanı sıra birden fazla platformda hızlı testler çalıştırırken dikkatlice optimize edilmiş ikili dosyaları aynı anda desteklemek için yerleşik kurallar, dahili olarak oluşturulan potansiyel olarak birden fazla işlemin her birinde doğru girişlerin, çıkışların ve komut satırı işaretlerinin ayarlanmasını sağlamak için büyük çaba gösterir.

Bu değişkenler, nadir durumlarda dil uzmanları tarafından kullanılacak bir yedek mekanizmadır. Bunları kullanmak isterseniz lütfen önce Bazel geliştiricileriyle iletişime geçin.

  • ABI: C++ ABI sürümü.
  • AR: Crosstool'daki "ar" komutu.
  • C_COMPILER: C/C++ derleyici tanımlayıcısı (ör. llvm).

  • CC: C ve C++ derleyici komutu.

    CC_FLAGS ile CC'yi her zaman birlikte kullanmanızı önemle tavsiye ederiz. Aksi takdirde, bunun tüm riski size aittir.

  • CC_FLAGS: C/C++ derleyicisinin genrules tarafından kullanılabilmesi için gereken minimum işaret grubu. Bu özellikle, CC birden fazla mimariyi destekliyorsa doğru mimariyi seçmek için işaretler içerir.
  • NM: Crosstool'daki "nm" komutu.
  • OBJCOPY: C/C++ derleyicisiyle aynı paketteki objcopy komutu.
  • STRIP: C/C++ derleyicisiyle aynı paketteki strip komutu.

Java araç zinciri değişkenleri

Aşağıdakiler Java araç zinciri kurallarında tanımlanır ve toolchains = ["@bazel_tools//tools/jdk:current_java_runtime"] (veya ana makine araç zinciri eşdeğeri için "@bazel_tools//tools/jdk:current_host_java_runtime") ayarlayan tüm kurallar tarafından kullanılabilir.

JDK'daki araçların çoğu doğrudan kullanılmamalıdır. Yerleşik Java kuralları, Java derleme ve paketleme konusunda yukarı akış araçlarının ifade edebileceğinden çok daha gelişmiş yaklaşımlar kullanır. Örneğin, arayüz JAR'ları, başlık arayüzü JAR'ları ve son derece optimize edilmiş JAR paketleme ve birleştirme uygulamaları.

Bu değişkenler, nadir durumlarda dil uzmanları tarafından kullanılacak bir yedek mekanizmadır. Bunları kullanmak isterseniz lütfen önce Bazel geliştiricileriyle iletişime geçin.

  • JAVA: "java" komutu (bir Java sanal makinesi). Bu durumdan kaçının ve mümkün olduğunda bunun yerine java_binary kuralı kullanın. Göreli yol olabilir. java işlevini çağırmadan önce dizinleri değiştirmeniz gerekiyorsa çalışma dizinini değiştirmeden önce yakalamanız gerekir.
  • JAVABASE: Java yardımcı programlarını içeren temel dizin. Göreli yol olabilir. "bin" adlı bir alt dizini olur.

Starlark ile tanımlanan değişkenler

Kural ve araç zinciri yazarları, TemplateVariableInfo sağlayıcısı döndürerek tamamen özel değişkenler tanımlayabilir. toolchains özelliği aracılığıyla bunlara bağlı olan tüm kurallar daha sonra değerlerini okuyabilir:

Starlark ile tanımlanan değişkenlere ilişkin bir örneği inceleyin.