Değişken Oluşturma

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

• Kullanım
• Önceden tanımlanmış değişkenler
• Önceden tanımlanmış genrule değişkenleri
• Önceden tanımlanmış kaynak/çıktı yolu değişkenleri
• Özelleştirilebilen değişkenler

"Make" değişkenleri, ""Make değişkeni" yerine koymaya tabi" olarak işaretlenmiş özelliklerde kullanılabilen genişletilebilir dize değişkenlerinin özel bir sınıfıdır.

Bunlar, örneğin, kullanıcı tarafından oluşturulan derleme işlemlerine belirli araç zinciri yolları eklemek için kullanılabilir.

Bazel, hem tüm hedeflerin kullanabileceği önceden tanımlanmış değişkenler hem de bağımlılık hedeflerinde tanımlanan ve yalnızca bunlara bağlı hedeflerin kullanabileceği özel değişkenler sağlar.

"Make" terimi geçmişten kalmadır: Bu değişkenlerin söz dizimi ve semantiği başlangıçta GNU Make ile eşleşmek için tasarlanmıştır.

Kullan

""Make değişkeni" yerine koymaya tabi" olarak işaretlenen özellikler, "Make" değişkenine FOO aşağıdaki gibi 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 bir hatayla başarısız olur.

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

my_attr = "prefix $@ suffix"

$ değerini dize değişmezi olarak yazmak için (yani değişkenin genişletilmesini önlemek için) $$.

Predefined variables

Predefined "Make" variables can be referenced by any attribute marked as "Subject to 'Make variable' substitution" on any target.

To see the list of these variables and their values for a given set of build options, run

bazel info --show_make_env [build options]

and look at the top output lines with capital letters.

See an example of predefined variables.

Toolchain option variables

• COMPILATION_MODE: fastbuild, dbg, or opt. (more details)

Path variables

• BINDIR: The base of the generated binary tree for the target architecture.

  Note that a different tree may be used for programs that run during the build on the host architecture, to support cross-compiling.

  If you want to run a tool from within a genrule, the recommended way to get its path is $(execpath toolname), where toolname must be listed in the genrule's tools attribute.

• GENDIR: The base of the generated code tree for the target architecture.

Machine architecture variables

• TARGET_CPU: The target architecture's CPU, e.g. k8.

Predefined genrule variables

The following are specially available to genrule's cmd attribute and are generally important for making that attribute work.

See an example of predefined genrule variables.

• OUTS: The genrule's outs list. If you have only one output file, you can also use $@.
• SRCS: The genrule's srcs list (or more precisely: the path names of the files corresponding to labels in the srcs list). If you have only one source file, you can also use $<.
• <: SRCS, if it is a single file. Else triggers a build error.
• @: OUTS, if it is a single file. Else triggers a build error.

• RULEDIR: The output directory of the target, that is, the directory corresponding to the name of the package containing the target under the genfiles or bin tree. For //my/pkg:my_genrule this always ends in my/pkg, even if //my/pkg:my_genrule's outputs are in subdirectories.

• @D: The output directory. If outs has one entry, this expands to the directory containing that file. If it has multiple entries, this expands to the package's root directory in the genfiles tree, even if all output files are in the same subdirectory!

  Note: Use RULEDIR over @D because RULEDIR has simpler semantics and behaves the same way regardless of the number of output files.

  If the genrule needs to generate temporary intermediate files (perhaps as a result of using some other tool like a compiler), it should attempt to write them to @D (although /tmp will also be writable) and remove them before finishing.

  Especially avoid writing to directories containing inputs. They may be on read-only filesystems. Even if not, doing so would trash the source tree.

Note: If the filenames corresponding to the input labels or the output filenames contain spaces, ', or other special characters (or your genrule is part of a Starlark macro which downstream users may invoke on such files), then $(SRCS) and $(OUTS) are not suitable for interpolation into a command line, as they do not have the semantics that "${@}" would in Bash.

One workaround is to convert to a Bash array, with

mapfile SRCS <<< "$$(sed -e 's/ /\\n/g' <<'genrule_srcs_expansion'
$(SRC)
genrule_srcs_expansion
) yazın ve ardından sonraki komut satırlarında $(SRCS) yerine "$$\{SRCS[@]}" kullanın. Bunun yerine daha güçlü bir seçenek olarak Starlark kuralı yazabilirsiniz.



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

  execpath, execpaths,
  rootpath, rootpaths, location ve
  locations adlı önceden tanımlanmış değişkenler, etiket parametrelerini (ör. $(execpath
  //foo:bar)) alır ve bu etiketle belirtilen dosya yollarını değiştirir.



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



  Önceden tanımlanmış yol değişkenlerine örnek


  

    

      execpath:  Bazel'in derleme işlemlerini yürüttüğü, execroot altındaki yolu belirtir.
    
    

      Yukarıdaki örnekte Bazel, tüm derleme işlemlerini Workspace kök dizininizdeki bazel-myproject sembolik bağlantısı tarafından bağlanan dizinde çalıştırır. empty.source kaynak dosyası, bazel-myproject/testapp/empty.source yoluna bağlanmıştır. Dolayısıyla, yürütme yolu (kökün altındaki alt yol) testapp/empty.source'tür. Bu, derleme işlemlerinin dosyayı bulmak için kullanabileceği yoldur.
    
    

      Çıkış dosyaları benzer şekilde düzenlenir ancak önlerine bazel-out/cpu-compilation_mode/bin alt yolu da eklenir (veya araçların çıkışları için: bazel-out/cpu-opt-exec-hash/bin). Yukarıdaki örnekte, show_app_output'ın tools özelliğinde göründüğü için //testapp:app 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 ön ek, aynı derlemedeki iki farklı CPU için aynı hedefin, sonuçların birbirini etkilemeden derlenmesini sağlar.
    
    

      Bu değişkene iletilen etiket tam olarak bir dosyayı temsil etmelidir. Kaynak dosyalarını temsil eden etiketler için bu durum otomatik olarak doğrudur. Kuralları temsil eden etiketler için kuralın tam olarak bir çıkış oluşturması gerekir. Bu değer yanlışsa veya etiket hatalı biçimlendirilmişse derleme hatayla başarısız olur.
    
  

  

    

      rootpath: Derlenmiş bir ikili dosyanın, ana depoya karşılık gelen çalıştırma dosyaları dizininin alt dizine göre çalışma zamanında bağımlılık bulmak için kullanabileceği yolu belirtir.
      Not: Bu yöntem yalnızca 
      --enable_runfiles etkinse çalışır. Windows'da bu özellik varsayılan olarak etkin değildir. Platformlar arası destek için bunun yerine rlocationpath kullanın.
    

      Bu, execpath ile benzerdir ancak yukarıda açıklanan yapılandırma ön eklerinin kaldırılmasını sağlar. Yukarıdaki örnekte bu, hem empty.source hem de app'ün, testapp/empty.source ve testapp/app olmak üzere yalnızca çalışma alanına göreli yollar kullandığı anlamına gelir.
    
    

      Harici bir depodaki dosyanın rootpath değeri repo, ../repo/ ile başlar ve depoya göreli yol ile devam eder.
    
    

      Bu, execpath ile aynı "yalnızca bir çıkış" koşullarına sahiptir.
    
  

  

    

      rlocationpath: Derlenmiş bir ikili dosyanın, çalışma zamanında bir bağımlılık bulmak için runfiles kütüphanesinin 
      Rlocation işlevine iletebildiği yol. Bu yol, runfiles dizininde (varsa) veya runfiles manifest'ini kullanarak bulunabilir.
    
    

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

      Harici bir depodaki dosyanın rlocationpath değeri repo, repo/ ile başlar ve depoya göreli yol ile devam eder.
    
    

      Bu yolu bir ikili dosyaya iletmek ve runfiles kitaplıklarını kullanarak dosya sistemi yoluna çözümlemek, bağımlılıkların çalışma zamanında bulunması için tercih edilen yaklaşımdır. rootpath ile karşılaştırıldığında, runfiles dizini mevcut olmasa bile tüm platformlarda çalışabilmesi avantajı vardır.
    
    

      Bu, execpath ile aynı "yalnızca bir çıkış" koşullarına sahiptir.
    
  

  

    location: Genişletilen özelliğe bağlı olarak execpath veya rootpath için eş anlamlı bir terimdir. Bu, Starlark öncesi eski bir davranıştır ve belirli bir kural için ne yaptığını gerçekten bilmediğiniz sürece önerilmez. Ayrıntılar için #2475
  



  execpaths, rootpaths, rlocationpaths ve locations, sırasıyla execpath, rootpath, rlocationpath ve location'ın çoğul varyasyonlarıdır. Birden fazla çıkış üreten etiketleri destekler. Bu durumda her çıkış, boşlukla ayrılarak listelenir. Sıfır çıkışlı kurallar ve hatalı biçimlendirilmiş etiketler derleme hataları oluşturur.



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



  Etiketlerin standart biçimde olması gerekmez: foo, :foo ve //somepkg:foo kullanılabilir.


Özelleştirilebilen değişkenler


  Özel "Make" değişkenlerine, "Make değişkeni yerine koyma işlemine tabi" olarak işaretlenmiş herhangi bir özellik tarafından referans verilebilir ancak yalnızca bu değişkenleri tanımlayan diğer hedeflere bağlı hedeflerde referans verilebilir.



  En iyi uygulama olarak, temel Bazel'e dahil edilmeleri için gerçekten iyi bir neden olmadığı sürece tüm değişkenler özel olmalıdır. Bu sayede Bazel, hedefi tüketen değişkenlerin dikkate almayacağı değişkenleri sağlamak için pahalı olabilecek bağımlılıkları yüklemek zorunda kalmaz.


C++ araç zinciri değişkenleri

  Aşağıdakiler C++ araç zinciri kurallarında tanımlanır ve toolchains =
  ["@bazel_tools//tools/cpp:toolchain_type"] değerini ayarlayan tüm kurallar tarafından kullanılabilir. java_binary gibi bazı kurallar, kural tanımlarında C++ araç zincirini dolaylı olarak içerir. Bu değişkenler otomatik olarak devralınır.



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



  Bu değişkenler, dil uzmanları tarafından nadiren kullanılacak bir yedek mekanizmadır. Bunları kullanmak istiyorsanız 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ıdır (ör. llvm).
  
  

    
CC: C ve C++ derleyici komutu.
    

      CC_FLAGS'ü her zaman CC ile birlikte kullanmanızı önemle Aksi takdirde tüm risk size aittir.
    
  
  
CC_FLAGS: C/C++ derleyicisinin genrules tarafından kullanılabilmesi için gereken minimum işaretler. Özellikle, CC birden fazla mimariyi destekliyorsa doğru mimariyi seçmek için işaretler içerir.
  


  
 DUMPBIN: Microsoft Visual Studio'dan Microsoft COFF Binary File Dumper (dumpbin.exe) 

  
 NM: crosstool'daki "nm" komutu. 
  
 OBJCOPY: C/C++ derleyiciyle 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") değerini ayarlayan tüm kurallar tarafından kullanılabilir.



  JDK'deki araçların çoğu doğrudan kullanılmamalıdır. Yerleşik Java kuralları, Java derleme ve paketleme için yayın öncesi araçların ifade edebileceğinden çok daha gelişmiş yaklaşımlar kullanır (ör. 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, dil uzmanları tarafından nadiren kullanılacak bir yedek mekanizmadır. Bunları kullanmak istiyorsanız lütfen önce Bazel geliştiricileriyle iletişime geçin.



  
 JAVA: "java" komutu (Java sanal makinesi). Bu durumdan kaçının ve mümkün olduğunda bunun yerine java_binary kuralı kullanın. Göreli bir 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 bir yol olabilir. "bin" adlı bir alt dizin bulunur.
  


Starlark tarafından 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, değerlerini okuyabilir:



  Starlark tarafından tanımlanan değişkenler örneğine bakın.